【面向对象】领域驱动设计核心

要理解领域驱动设计，首先要明白什么是领域模型，DDD只是提供了领域模型落地实践的方法论。

1.领域模型

1）什么是领域模型？

领域模型表达的是业务概念及概念之间的关系，领域模型沉淀和表达业务认识，提炼共性，支持拓展。

2）领域模型解决什么问题？

• 重复建设
• 提供的服务不稳定
• 语言不统一
• 业务资产沉淀

2.关于领域建模

1）什么是领域建模？

领域建模，就是确定一个概念的过程，也即把概念说清楚（建模，是认知升级的过程）。

2）为什么领域建模困难？

领域模型反映的是对概念的认知，然而认知本身就是困难的

• 概念是认知的基础（抽象，分解（关注点分离））
• 概念存在矛盾，往往是认知升级的机会
• 只是通过概念和概念的关系获得传承

PS：这也解释了为什么一个新公司建立之初要去业界成熟的公司挖人，可以减少很多试错的成本

3）怎么进行领域建模？

首先要明确：商业世界快速变化，一个大而全领域不能快速应对，正确的做法是把领域划分细致（专精），通过子领域的连接组合创建丰富的世界。=> 子领域：做一件事，把它做好

PS：可组装商业，可组装企业，可组装架构，组装式应用是未来企业组织的数字孪生（PBC）

核心要素：

• 明确领域愿景
• 守护领域边界（领域很容易被腐化掉，换言之就是领域边界被突破了）
  • 示例：评论服务为了适应业务先后增加了，积分，会员…
  • 解决方案：分离关注点，通过契约/接口/事件分离领域
• 围绕领域模型设计服务（不要做自己领域外的事情）

注意：领域愿景，领域模型，领域服务应该随着业务发展和认知升级持续演进

4）如何在业务沟通/服务设计中发现和应用领域模型？

聚焦于功能，收敛于模型

1. 通过猜想（业务目标->业务场景->业务规则），建立关于领域模型的概念假设
2. 使用用例场景进行反驳，促进领域模型逐步求精

3.领域驱动设计

DDD 在战术和战略两个层面提供了领域建模的方法论，如统一语言，限界上下文，上下文映射，四色建模，事件风暴等等…

1）统一语言

规则：任何在需求中描述出的概念，都必须出现在领域模型中。如果需求描述中存在概念间的关系，领域模型中也必须有这个关系。

强迫团队在沟通需求时使用领域模型，是确保领域模型始终有效切同步演化的方式。

2）事件风暴

一个打车的示例：

3）用领域模型指导架构设计和领域协作

1. 客户-供应商：提供方定制化支持消费方（1对1）
2. 标准开放服务：提供者实现服务化，提供稳定标准的服务，消费方使用这些成熟的服务
3. 追随者：消费方全部使用提供者的服务
4. 防腐层：消费房不直接使用提供者的服务，再封装一次
5. 共享内核

PS：如果一开始识别不出来两个域是独立的，那么尽量合到一起后续演进时再分离（大多数场景），但有的场景在一开始可以识别出分属独立的域（比如淘宝-支付宝），虽然在一开始是客户供应商关系，但是不能只在合在一起，不然有了新的场景也无法支持。

4）常见领域建模错误

• 技术：把数据库当模型
• 产品：直接将业务名词当模型

4.MVC vs DDD

MVC 是面向过程，而流程往往是变化的，DDD是MVC之后演进来的，抽离出了领域层（洋葱架构），相比面向流程，核心模型是相对稳定的，体现在编码层面（战术设计），DDD围绕着以领域为核心出现了四层和六层架构。

1）战略设计：

• MVC：流程 -> 数据表？
• DDD：流程 -> 领域？边界？能力？依赖？

2）战术设计：

• MVC：贫血模型 <- service 为核心 -> 快速开发
  • service 囊括所有处理逻辑，包括转换好 dao 需要的数据，直接调用 dao 存数据
  • 应用中的模型仅承载数据即可
• DDD：充血模型 <- domain 为核心 -> 高内聚低耦合
  • domain 作为核心，需要 infra 提供基础设施，需要 service 提供编排
  • 应用中的模型需要有自己的行为

总结

模型好不好，结果来反映 => 效率（开发/扩展）

• 理想模型是，概念剥离好，可复用程度高
• 不好的模型会成为负债，最终会被淘汰掉