团队大多数项目都是基于DDD分层架构开发的，而不是传统的MVC模式，这就让很多之前没有接触过DDD思想的同学在刚开始接触项目的时候有点懵。那么什么DDD？这种DDD项目结构和之前的有哪些不同，我该如何开发我的代码，开发不同职责的代码该放在哪里？下面就我的理解，说一说DDD的分层架构。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
传统开发分层文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
传统的数据驱动开发模式，View、Service、dao这种三层分层模式，我们会很自然的写出过程式代码，这种开发方式中的对象只是数据载体，而没有行为，是一种贫血对象模型。以数据为中心，以数据库ER图为设计驱动，分层架构在这种开发模式下可以认为是数据处理和实现的过程。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
image.png文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
什么是DDD？文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD 全称是 Domain-Driven Design，中文叫领域驱动设计，是一套应对复杂软件系统分析和设计的面向对象建模方法论。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
以前的系统分析和设计是分开的，导致需求和成品非常容易出现偏差，两者相对独立，还会导致沟通困难，DDD 则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
image.png文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD的术语与基本概念文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
领域：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
领域就是范围。范围的重点是边界。领域的核心思想是将问题逐级细分来减低业务和系统的复杂度，这也是 DDD 的核心。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
2.子域：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
领域可以进一步划分成子领域，即子域。这是处理高度复杂领域的设计思想，它试图分离技术实现的复杂性。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
3.核心域:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
在领域划分过程中，会不断划分子域，子域按重要程度会被划分成三类：核心域、通用域、支撑域。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
4.通用域:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
中间件服务或第三方服务。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
5.支撑域:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
企业公共服务。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
6.统一语言：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
映射概念：统一概念。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
定义上下文的含义。它的价值是可以解决交流障碍，不管是 RD、PM、QA 等什么角色，让每个团队使用统一的语言（概念）来交流，甚至可读性更好的代码。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
7.限界上下文：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
定义上下文的边界。领域模型存在边界之内。对于同一个概念文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
8.聚合:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
聚合概念类似于包的概念，每个包里包含一类实体或者行为，它有助于分散系统复杂性，也是一种高层次的抽象，可以简化对领域模型的理解。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
在定义聚合的时候，应该遵守不变形约束法则：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
聚合边界内必须具有哪些信息，如果没有这些信息就不能称为一个有效的聚合；文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
聚合内的某些对象的状态必须满足某个业务规则：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
一个聚合只有一个聚合根，聚合根是可以独立存在的，聚合中其他实体或值对象依赖与聚合根。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
只有聚合根才能被外部访问到，聚合根维护聚合的内部一致性。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
9. 聚合根：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
一个上下文内可能包含多个聚合，每个聚合都有一个根实体，叫做聚合根，一个聚合只有一个聚合根。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
10. 实体：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
Domain 或 entity。（有唯一ID）文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
11. 值对象：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
Domain 或 entity。（没有唯一ID）文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
常见的两种领域模型文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
贫血型文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
简单来说，就是 Domain Object 包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到 Service 层。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
这种模式不在 Domain 层里依赖 DAO。持久化的工作还需要在 DAO 或者 Service 中进行。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
缺点：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
Domain Object 的部分比较紧密依赖的持久化 Domain Logic 被分离到 Service 层。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
Service 过于厚重。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
2. 充血模型文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
充血模型和第二种模型差不多，区别在于业务逻辑划分，将绝大多数业务逻辑放到 Domain 中，Service 是很薄的一层，封装少量业务逻辑，并且不和 DAO 打交道。即：Service (事务封装) —> Domain Object <—> DAO文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD分层架构文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
目前我们团队项目分层主要是按照入下图DDD分层进行。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
image.png文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
交互层：Web项目、Task项目、其它项目，为最顶层。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
应用层：Service API项目和Service Provider项目，API项目不能对其它项目进行依赖，是整个领域的边界，向第三方提供接口。API项目包含了DTO对象和服务接口。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
领域层：Domain项目，纯粹的领域模型，不包含任何数据访问，纯OO实现。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
基础设施层：拆分为Component项目和Repository项目，Component项目提供公共组件，Repository项目提供领域存储，但是Domain项目不依赖于Repository项目，相反是Repository项目依赖于Domain项目，Repository项目以依赖注入的方式，注入到领域层和应用层。该设计与DDD的架构设计是存在差异的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
整个应用系统与Spring高度集成。Factory基于Spring创建prototype的聚合根、实体、VO。聚合根使用依赖注入动态注入Repository实现。因此，整个系统的依赖关系与高层架构设计吻合。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD好处文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
最大好处就是所有参与者围绕一个统一一致的领域模型工作，传统的分析模型和设计模型不再割裂，不管是做设计、做分析还是写代码、写文档，脑海中所构建的画面都是一致的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD 是一个软件开发过程，它显式地把领域和设计放到了软件开发的核心，软件人员和业务人员被受到同样的重视，他们合作来构建领域模型，使得软件的交付质量更高且维护成本更低。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD 提出的分层架构，有效分离了业务复杂度和技术复杂度，凸显了领域模型，使得领域层的代码和领域模型保持高度一致。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
统一语言非常重要，每个概念在各自的上下文中是清晰的无歧义的，同时要控制领域模型的复杂度，于是 DDD 在战略上提出了分离子域（问题域空间）和拆分 BC（解决方案空间）的模式，BC 间通过 Context Mapping 来集成。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html
DDD 在战术层面提出了很多模式（聚合，实体，值对象，服务，工厂，仓储），对领域模型中的元素进行了分类，并给出了每类元素在领域模型中的职责和特征，降低了领域模型的构建成本文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26999.html