DDD：Domain-driven Design（领域 - 驱动 -> 设计)
->领域驱动领域模型设计
->领域模型驱动代码实现
https: www
DDD：Domain-driven Design（领域 - 驱动 -> 设计)
->领域驱动领域模型设计
->领域模型驱动代码实现
摘自网络（汤雪华的博客）
《概念总结》
- 领域就是问题域，有边界，领域中有很多问题；
- 任何一个系统要解决的那个大问题都对应一个领域；
- 通过建立领域模型来解决领域中的核心问题，模型驱动的思想；
- 领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
- 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
- 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
- 领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
- 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地；
《拆分领域》
领域建模的基础是要先理解领域，让自己成为领域专家。如果做到了这点，我们就打好了坚实的基础了。
但是，有时一个领域往往太复杂，涉及到的领域概念、业务规则、交互流程太多，导致我们没办法直接针对这个大的领域进行领域建模。
所以，我们需要将领域进行拆分，本质上就是把大问题拆分为小问题，然后各个击破的思路。
然后既然把一个大的领域划分为了多个小的领域（子域），那最关键的就是要理清每个子域的边界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撑子域；然后，还要思考子域之间的联系是什么。
那么，我们该如何划分子域呢？我的个人看法是从业务相关性的角度去思考，也就是我们平时说的按业务功能为出发点进行划分。
《细化子域》
- 梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言；
- 梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则，余额不能小于零等；
- 梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景；
- 梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等；
*关于领域概念的梳理，我觉得可以采用四色原型分析法
《领域模型设计》
DDD原著中提出了很多实用的建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。
- 划分好边界上下文，通常每个子域（sub domain）对应一个边界上下文（bounded context），同一个边界上下文中的概念是明确的，没有任何歧义；
- 在每个边界上下文中设计领域模型，具体的领域模型设计方法有很多种，如以场景为出发点的四色原型分析法，或者我早期写的这篇文章；这个步骤最核心的就是找出聚合根，并找出每个聚合根包含的信息；
- 关于如何设计聚合，可以看一下我写的这篇文章；
- 画出领域模型图，圈出每个模型中的聚合边界；
- 设计领域模型时，要考虑该领域模型是否满足业务规则，同时还要综合考虑技术实现等问题，比如并发问题；领域模型不是概念模型，概念模型不关注技术实现，领域模型关心；所以领域模型才能直接指导编码实现；
- 思考领域模型是如何在业务场景中发挥作用的，以及是如何参与到业务流程的每个环节的；
- 场景走查，确认领域模型是否能满足领域中的业务场景和业务流程；
- 模型持续重构、完善、精炼；
《领域模型的核心作用》
- 抽象了领域内的核心概念，并建立概念之间的关系；
- 领域模型承担了领域内的状态的维护；
- 领域模型维护了领域内的数据之间的业务规则，数据一致性；
![[.NET领域驱动设计实战系列]专题二：结合领域驱动设计的面向服务架构来搭建网上书店](https://cdnss.haodaima.top/uploadfile/2024/0314/20240314061944767.gif)
