domain-driven design 领域驱动设计，缩写DDD。它是一种根据实际持续演化的业务，进行分析与拆分以达到建立低耦合高内聚的软件设计方法。

它与传统的 data-driven design有很大的不同。传统的data-driven design开发人员是了解需求背景后，先设计数据库表，再写业务逻辑，业务边界和划分完全凭实际开发人员的判断，并没有一个指导方法。

domain-driven design需要开发人员先了解业务背景，然后根据业务思考领域，确定领域边界和能力后，再根据业务进行领域内的能力设计，数据表和存储可以再领域设计完成之后再进行。

domain-driven design是一种软件设计指导方法论，按照这个方法论，开发人员可以设计出扩展性和维护性很好的软件架构。按照这种方法论设计出来的软件架构可以满足业务的不断演化。

当业务很复杂时，开发人员往往会陷入不知如何设计系统架构，软件架构需要满足当前业务和也要满足未来业务扩展和变更。DDD思想可以帮助开发人员解决这个难题。

如果你的业务场景较简单，则没必要使用DDD思想进行架构设计,因为DDD会给你的软件架构带来很多复杂度。

本篇文章解释DDD思想中的核心概念。

为什么学习DDD

  1. 提高开发优秀软件的技巧。
  2. 增加你的项目成功率。
  3. 提升你的产品商业竞争力。
  4. 帮助你根据业务建立模型。
  5. 帮助你开发出可扩展和执行的大型软件。

战略设计

在DDD实践可以分为两个阶段：战略设计与战术设计。

战略设计目的是将，业务领域拆分成具有高内聚，低耦合的一个个子域。

事件风暴：业务人员、研发人员、领域专家、产品人员聚集在一起。通过头脑风暴的形式，对齐对业务的认知，划分出领域、识别出核心子域、确定限界上下文和通用语言。

领域

领域 表示一个组织的业务范围以及在其中所进行的活动。例如：通过网络卖商品的公司，它的领域就是电子商务；提供货品邮寄服务的公司，它的领域是快递。

领域的边界是清晰的通过业务就可以区分出来，但领域往往是庞杂的，从业务角度看它涉及很多场景。DDD是将领域进行拆解和细化，首先识别出领域中的子域（核心子域、通用子域、支撑子域），确定限界上下文，通用子域内的通用语言。

通过以上步骤，可将复杂的领域变成结构清晰、易于理解和维护。

子域

领域是一个业务的整体，子域是业务逻辑上的相对独立的一部分。领域是有多个这样相对独立的子域组成。

核心域

决定业务成败的核心子域，被称为核心域。没有太多个性诉求。

支撑子域

是业务重要的组成部分，但不是核心，是必须存在的功能，它不会对产品核心竞争力产生影响。

通用子域

被多个子域使用的通过功能可以被划分成通用子域。

限界上下文与通用语言

每个子域都应该有清晰的边界，边界之内的内容构成了子域。抽象的子域边界被称为限界上下文。

限界上下文内的业务概念具有一致性，但不同的限界上下文中相同的业务概念具有不同的名称。

例如：订单域中的商品，在物理域中会被成为货物。在电子商务业务领域中它们其实指的是一个概念。

上下文映射图

在一个复杂业务中，不同的子域需要协同配合才能完成一个业务功能。
子域之间往往存在着上下游关系。
上下文映射图就是说明领域之间上下游关系图。

战术设计

领域划分完成后，剩下工作是领域内的设计和实现。这部分被称为战术设计。
在DDD中战术设计包含几个部分：聚合、值对象、实体、领域事件。
它为实现领域功能提供支持。

实体

具有唯一标识，包含业务含义的充血模型。
在领域内的每个实体是唯一的，它包含业务的数据还包含业务的行为。

值对象

用于描述领域中某个特征对象，生成后不可改变。往往作为实体的属性存在，也可独立存在。

聚合

具有相关性的实体与值对象集合，组成聚合。聚合是限界上下文（子域）内部的边界划分。
一个限界上下文可以有多个聚合组成，并且只有一个聚合根。
聚合根做为一种特殊的实体，用于管理聚合内部的实体与值对象，并将自身暴露给外部进行引用。

聚合的一致性边界

  1. 生命周期的一致性，聚合对外的生命周期保持一致，聚合根生命周期结束，聚合的内部所有对象的生命周期也都应该结束。

  2. 事务的一致性，这里的事务指的是数据库事务，每个数据库事务指包含一个聚合，不应该有垮聚合的事务。

领域事件

领域事件：领域内发生的事情，通过它可以在限界上下文内同步信息。并且可以对外提信息并实现解耦。

DDD架构实践

DDD围绕核心域进行实际开发。它支持多种不同的架构风格，根据业务需要可以选择合适的架构和架构模式。

分层

DDD系统传统的分层架构包好四层：用户接口层、应用层、领域层、基础设施层。

根据 面向对象的 依赖倒置原则：

  1. 高层模块不应该依赖底层模块，二者应该依赖于对象
  2. 抽象不应该依赖于细节，细节依赖于抽象

可以将传统的分层架构优化一下：

六边形架构

六边形架构，将业务核心包裹在内部，外界通过应用层的API与内部交互，外部不关心内部如何实现。
六边形架构又称端口适配器架构。

CQRS

CQRS(C0mmand-Query Responsibility Segregation):命令-查询分离架构模式。将业务中的对于数据的查询与数据命令分开处理。

参考

https://xie.infoq.cn/article/9513e264857230d2c427e2272