DDD-领域驱动设计入门

领域驱动设计概述 Domain driven design summary

DDD(Domain Driven Design)
即领域驱动设计，核心是不断提炼通用语言并用于与领域专家等团队所有成员交流，并用代码来表达出一个与通用语言一致的领域模型。

背景
这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代，DDD早在2004年就由埃里克·埃文斯提出，但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意，也就是微服务盛行之后(这儿需要说明的是，微服务最早的提出者不是Martin Fowler，而是Fred George)，DDD再次回到人们视野中间

领域DOMAIN： 软件系统要解决的问题域，是有边界的。领域一般包含多个子域，子域根据其功能划分为核心域、通用域、支撑域。

限界上下文BOUNDED CONTEXT：描述领域边界，一个限界上下文可能包含多个子域，但一般实践上都以一对一为好。应用单元和部署单元一般也与限界上下文一致。

领域模型DOMAIN MODEL：对我们软件系统中要解决问题的抽象表达（解决方案）。模型一般在一个限界上下文中有效。

限界上下文映射BOUNDED CONTEXT MAPPING：多个上下文之间如何进展系统交互集成。

• 聚合根
• 实体
• 值对象
• 领域事件
• 仓储定义
• 领域服务
• 工厂
• 限界上下文映射的反腐层定义

分层架构与六边形架构 Hierarchical and hexagonal

分层分包：
复杂是我们软件生涯的一生之敌。

分层是除“模块化”之外最古老的架构模式，冯诺依曼计算机模型是模块化的架构，但同时计算机世界也是层层叠加的。分层分包的本质就是隔离，人处理难题的能力是有限的，无法同时处理很多复杂的事情，所以不把所有东西都放在同一层次，譬如行政体系也是分层的。隔离使得各个层次职责更清晰，更容易管理。

分层的原则是只能上层调用下层，而不能反过来，反之容易导致循环依赖。分包的原则是，同一个包中的对象天然是亲和的，同时对包外的对象是不亲和(隔离)的。

分层架构 & 面向过程设计 - MVC

1. 包划分：所有model放一个包，所有service放一个包，所有mapper放一个包。
2. 服务依赖：SpuController -> SpuService -> SpuMapper -> Mybatis
3. 创建时数据流向：SpuDTO -> SpuDO -> Table
4. 失血模型：只包含字段，和get/set方法，SpuDO本身无法执行任何行为

缺点：
一个服务方法几乎包含了所有的逻辑，负责校验、获取外部信息、组装、转换SpuDTO为SpuDO、并调用SpuMapper保存到数据库，SpuDO为失血模型。
耦合性强，在各种service（如MaterialService，CategoryService）内部注入，重构/扩展性差。

优点：
在逻辑很简单场景下，crud迭代最快。 MVC保证了代码最差也差不到哪去（基本总是最差）

六边形架构 & 面向对象设计 - DDD

1. 包划分：以业务划分包，同业务的identity、valueObject、event、repository、service等放在一个包下。
2. 服务依赖：SpuService只是调用领域服务和仓储等来串流程，不包含业务逻辑，如校验等。
3. 分治：采用分治法，将数据、约束、行为等划分到最能表达它的领域模型中。
4. 充血模型：包含字段和行为，如校验在构造和set时内置，方法体现业务操作如changeName，不是单一的update动作。

优缺点：
DDD如果做的差，会比MVC还要差，如果做的好，的确可以应对业务的变化（了解业务，预测业务的变化）。
业务逻辑清晰度高。
防腐层隔离变化。
充血模型扩展性高（当MVC耦合成一团💩山的时候，还敢随便改SpuDO的信息吗？除非读懂每一个Service的调用过程）
各领域自治，可以自我发展。

六边形架构又称“端口和适配器模式”，是计算机博士Alistair Cockburn提出的一种具有对称性特征的架构风格。
在这种架构中，系统通过适配器的方式与外部交互，将应用服务于领域服务封装在系统内部。

代码分享 Code Sharing

包划分
gate: 对外暴露的服务
rest：对外暴露的rest服务
application：应用服务层
domain：领域层
category: 分类
unit: 单位
sku: 规格
spu: 商品库
infra：基础设施层
repo：仓储实现
mapper: 数据库交互

探讨Discuss

如何判断一个项目是否需要用DDD?

业务：快速变化
需求变更快，需求迭代快，业务扩展快的项目。

开发人员：3-5年经验
需要熟练应用过很多设计模式，有了这些经验才能理解为什么这么设计，才能不偷懒的去做这件事，否则很容易对领域造成污染。

时间：充分
需要有充分的时间去划分业务，设计领域，需要更多的类，编写更多代码量。

by：9月9日 - 高世庆 - DDD驱动开发设计，商派内部技术分享会