一、领域驱动设计-战略篇-CFANZ编程社区

1、写在前面

**领域驱动设计（Domain-Driven Design，DDD）**是一个有关软件开发设计的方法论，它提出了从业务设计到代码实现一致性的要求，不再对分析模型和实现模型进行区分。简言之，从代码结构我们就可以直接理解业务的设计，命名得当的话，非程序人员也可以“读”代码。

2003 年的时候，Eric Evans 发表了一篇著作**《Domain-driven Design: Tackling Complexity in the Heart of Software》**，正式定义了领域的概念，开始了 DDD 的时代,但 DDD 的发展确是一直不温不火,这个时候 spring 的贫血模型，则是风靡全球。

2013 年，Vaughn Vernon 写了一本**《Implementing Domain-Driven Design（实现领域驱动设计）》**进一步定义了 DDD 的领域方向，并且给出了很多落地指导，它让人们离 DDD 又进了一步。

而后，随着业务复杂性的提高，人们发现单体应用带来的迭代难，重构难，维护难等问题，越来越难以解决，于是在分而治之的思想下，诞生了微服务，一改以往单体应用，而拆分为多个子应用，一下子让人眼前一亮，于是我们没日没夜地拆分服务，加之微服务提供的注册中心、熔断、限流等解决方案，我们用得不亦乐乎。

但在人们在踩过诸多拆分服务的坑（拆分过细导致服务爆炸、拆分不合理导致频繁重构等）后，人们开始思考，到底有没有一种方法论可以指导人们更加合理地拆分服务呢？众里寻他千百度，DDD 却在灯火阑珊处，有了 DDD 的指导，加之微服务，再应对复杂业务场景上，才算是有了一个相对完美的解决方案。

一句话总结：领域驱动设计（DDD）既是一种开发思想体系，也是一种软件开发的方法论，它旨在管理为复杂问题域编写的软件的创建和维护工作。DDD 是模式、原则和实践的集合，它可以被应用到软件设计，以管理复杂性。

2、为什么使用 DDD

a、DDD 要求领域专家和开发者一同工作，这样开发出来的软件能够准确传达业务规则。
b、准确传达业务规则 的意思是说，软件就像是领域专家是编码人员时所开发出来的一样。
c、可以帮助团队人员的自我提高，没有任何一个领域专家或管理者敢说自己对业务已经了如指掌了，业务知识需要长期的学习。在 DDD 中，每个人既是学习者，同时也是知识的贡献者
d、在领域专家、开发者和软件本身之间不存在“翻译”，也就是当大家都是用相同的语言进行交流时，每个人都能快速听懂他人所说。
e、DDD 中，设计就是代码，代码也是设计，两者是统一的，设计是关于代码如何工作的，最好的编码设计来源于多次试验，这得益于敏捷的发现过程。
f、DDD 同时提供了战略设计和战术设计两种方式，战略设计帮助我们理解哪些设计是最重要的；哪些既有的软件资产，可以直接拿来使用的；那些人员应该被加入到团队中；战术设计则是帮助我们创建 DDD 模型中的各个部件。
g、使用 DDD 的业务价值
- 1）、你获得了一个非常有用的领域模型
- 2）、你的业务得到了更准确的定义和理解
- 3）、领域专家可以为软件设计做出贡献
- 4）、更好的用户体验
- 5）、清晰的模型边界
- 6）、更好的企业架构
- 7）、敏捷、迭代式和持续建模
- 8）、使用战略和战术新工具

实施DDD所面临的挑战

a、为创建通用语言腾出时间和精力
b、持续地将领域专家引入项目
c、改变开发者对领域的思考方式（需要加入从业务角度看问题的思考方式）

3、DDD 设计和传统设计比较

1）、Spring 传统三层架构

其中 controller + jsp/thymeleaf 等可以认为是用户展示层,相信大部分同学都是从 SSM 框架入门的,大一些的项目可能会是前后端分离,即后端仅剩 controller 用于控制和前端的页面及数据交互.

如上图所示, spring 所提倡的简单的 java beans （即 pojo） ,相比以前的 ejb 大大简化了开发难度。

2）、DDD下的分层架构

在这里插入图片描述

变化

1、controller 层更加纯粹
- 原三层架构， controller 可能会聚合多个 service 层的调用
- 新的分层架构，纯粹作为与前端或外部系统交互的数据转换层,不再包含业务逻辑.
2、service 层改为 Appliaction Services,当然不是说改个名字就是变化,主要体现在对service进行分级,打薄,
- Appliaction Services作为更高级别的抽象
- 新增领域层,抽离原service层的部分逻辑到领域层的领域服务和领域对象中.
3、领域层分为聚合和领域服务.其中聚合包括实体+值对象,实体和值对象不像 spring 提倡的贫血模型（仅包含get set方法的简单对象）,是包含了业务逻辑的丰富对象（即DDD所提倡的充血模型对象），传统三层架构更像是面向过程编程,业务全部集中在service层,或许大家都在service层写过大量的数据校验代码,整个业务方法冗长,即使做了方法的提取封装,但整体仍然会有凌乱的感觉,但DDD则更符合面向对象的设计,按照DDD的架构分层,各层级之间的分级更加明确,service层的含义表述则会更加清晰简洁,而聚合和领域服务的粒度更小,更加的内聚.
当然 DDD 与传统设计的远不止以上的区别，上面的视角仅仅是从架构设计的角度

4、战略设计阶段：DDD 中的重要的一些概念

1）、战略设计

在这里插入图片描述

2）、战术设计

3）、领域 & 子领域

4）、核心域 & 通用域 & 支撑域

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域（每种子域一般包括多个限界上下文）。

核心域：决定产品和公司核心竞争力的子域，它是业务成功的主要因素和公司的核心竞争力。从战略角度讲，企业应该给予核心域最高的优先级、最资深的领域庄家和最优秀的开发团队。实施 DDD 的过程中，我们将主要关注核心域。
通用域：没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。
支撑域：有时我们会创建或购买某个限界上下文来支撑我们的业务，它对应业务某些重要的方面，但却不是核心，这样的子域便是支撑域。