DDD领域驱动设计的核心域和精炼

DDD领域驱动设计的核心域和精炼

1 领域

用以确定边界。

DDD按规则细分业务领域，细分到一定程度，DDD会将问题范围限定在特定边界，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。

领域就是该边界内要解决的业务问题域。其越大，则业务范围越广。

1.1 领域模型的特点

对业务领域建模：

• 细粒度的类，易扩展，易复用
• 可应对复杂业务逻辑
• 需要经验

简单的领域模型：

• 几乎和DB中的表一一对应
• 复杂领域模型
• 使用了继承，组合，设计模式等各种手段

2 子域

领域可再划分为多个子领域，即子域。每个子域对应一个更小的问题域或业务范围。

DDD是处理复杂领域的设计思想，它试图分离技术实现的复杂度。每个细分的领域都有一个知识体系，即DDD的领域模型。在所有子域研究完后，就建立了领域模型。

比如酒店行业，一开始的酒店核心系统是单体架构，后来业务发展，开始转型中台，引入微服务。微服务架构就需划分业务领域边界，建立领域模型，并实现微服务落地。可根据业务关联度及流程边界将酒店领域细分为：预订，入住，退房，客房服务，点餐等领域事件。

• 网上预订，入住，退房。是酒店领域一定要有的功能，这就是核心子域。
• 客房服务，点餐等不影响主要功能的就是支撑子领域。
• 在预订这个限界上下文内可以建立预订的领域模型的领域模型最后映射到系统就是预订微服务。

不同行业的业务模型可能不同，但领域建模过程类似，核心思想都是将问题域逐步分解，降低业务理解和系统实现的复杂度。

实际项目划分出的子域更多，但并非每个子域都一样重要。所以，还要继续划分子域，根据自身重要性和功能属性划分为：

2.1 核心域（Core Domain）

决定业务成功和公司核心竞争力的子域，整个系统最重要部分。Eric Evans 曾提出如下问题助识别核心域：

• 为何这系统值得写？
• 为何不直接买个？
• 为何不让外包写？

若你对这几个问题的回答能帮你找到这个系统非写不可的理由，则它就是核心域。如电商系统的订单、商品服务。

2.2 支撑子域（Supporting Subdomain）

不是你的核心竞争力，但又得做，市场无现成方案的子域。既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又必需。

具有企业特性，但不具通用性，如：

• 数据代码类的数据字典等系统
• 排行榜，可能根据各种信息排名，这种东西没人会按你需要做个，但对你自己，又是扩展自己系统的重要举措
• 调用银联、支付宝等第三方支付，即下游
• 报表系统
• 监控系统

2.3 通用域（Generic Subdomain）

无太多个性化需求，同时会被多个子域使用的通用功能子域。如认证、权限等，无企业特点限制，无需太多定制化。

行业里都这么做，即便不自己做，也不影响业务运行。如很多 App 要给用户发通知，这种功能完全可买个服务，丝毫不影响业务运行。

2.4 划分子域的意义

划分子域就是在区分不同概念，让他们各司其职。为了区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度和资源投入策略不同：

• 核心域全力投入
• 支撑域次之
• 通用域甚至可以直接花钱买服务

3 什么是精炼

精炼是把一堆混杂在一起的组件分开的过程，以便通过某种形式从中提取出最重要的内容，而这种形式将使它更有价值，也更有用。

如经典电磁学的全部内涵可精炼为以下四个方程：

而模型就是知识的精练。

3.1 动机

把最有价值的那部分提取出来，正是这部分使我们的软件区别于其他软件，并让其物有所值，这个部分就是CORE DOMAIN。领域模型的战略精炼包括：

1. 帮助所有团队成员掌握系统的总体设计及各部分如何协调工作
2. 找到一个具有适度规模的核心模型并把它添加到通用语言中，从而促进沟通
3. 指导重构
4. 专注于模型中最有价值部分
5. 指导外包、现成组件的使用及任务委派

3.2 案例

哪些是核心域呢？零售系统最关键的：

• 用户体验
• 运营盈利最大化

商品域、设备域是通用子域

支付域、用户域是支撑子域。

4 总结

领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，映射成系统就是微服务。

• 战略设计要明确核心域，团队尽量减少非核心域投入
• 核心域的建立总是伴随着精炼，精炼有两种方法
• 从个人发展角度，程序员也要尽量投入核心域的工作

参考

• ​​https://www.bilibili.com/video/BV1Fv41157kW?p=2​​

文章转载自公众号： JavaEdge