领域驱动设计是一套针对软件建模和设计的方法论，尤其适合运用在复杂系统的设计上，它强调从业务出发，合理的划分领域边界后进行建模，以保证能构建出生命力强大，适合长期演进的架构，而这点与微服务拆分的思路不谋而合，因此领域驱动设计也经常被用于指导微服务的拆分

在领域驱动设计中，主要有四大核心类业务概念，它们分别是

• 领域
• 限界上下文
• 聚合
• 领域模型

在做实际软件设计时，我们一般会先根据业务划分出业务领域模型，然后一层一层的划分出子域，当子域划分到合适的粒度时开始建立领域对象，确立完领域对象后根据模型在业务中是否会产生歧义划分出限界上下文，在上下文中确立领域模型的聚合

核心概念

领域

领域的定义是：从事一种专门活动事业的范围，部类或部门，在软件设计中，即是我们要解决的业务问题的范围，既然是范围，那必然会有边界，在领域驱动设计中，如何划分好边界可谓是重中之重，领域可以进一步的被划分为子域，子域是将父域的所解决的业务问题拆分成更小的问题，从而确立子域的边界。

领域拆分的过程中会细分成不同的子域，子域根据自身的重要性和功能属性分为三类，它们分别是：核心域、通用域和支撑域

核心域

核心域由产品的核心功能构成，它是由产品的业务战略所决定的，一个产品在不同的时期核心域可能不同。核心域应该被投入最好的资源，技术团队需要保证自己对核心域的绝对掌控能力

通用域

通用域是由产品中可复用的功能组成，通用域提供的功能可以被多个子域所复用，技术团队应尽量保证通用域的标准化和复用性强，由于强调标准化，因此它也往往不太会有太多个性化的需求

支撑域

支撑域往往是产品中的一些次要功能，它们是产品必要功能的一部分，但并非代表产品核心竞争力的功能，如果技术团队经历有限，可以尝试将这些功能的开发外包出去

通过划分领域，将复杂的业务问题逐渐分解成一个个较小的业务问题，可以帮助减小软件设计的复杂性，这种思想有点类似于算法中的分治思想，当领域划分完毕后，技术团队也能通过领域的分类来判断该如何分配开发资源

领域模型

领域划分完之后，就可以在领域边界内进行建模了，通过分析业务表述中出现的重要名词和相关的动作，我们可以总结出业务相关的领域模型，领域模型分为两大类：实体和值对象

实体

实体是具体的业务对象，它的特征是，具有唯一的标识符，无论实体的属性如何改变，实体本身的业务意义都不会发生变化

值对象

值对象时若干个属性的集合，逻辑上是实体属性的一部分，用于描述实体的特征，例如人可以作为一个实体，而人的通信地址的集合则可作为一个值对象嵌入

限界上下文

限界上下文划分了领域的边界，限定了什么功能该包含在服务中而什么功能不该包含，通常由多个聚合组成，它是划分出最小粒度子域下的非真自己，所有的术语和业务对象在限界上下文中才能有确切的含义。限界上下文在实际应用中经常被用来划定微服务的边界

聚合

聚合是组合实体与值对象协同工作，实现的一种不变的业务规则，它有上下文的边界，因此也通常在上下文边界内被定义

聚合根

聚合根是聚合中最重要的一个实体，也被称为根实体，它是外部访问聚合中实体的唯一入口，通过这种方式，我们可以避免一个聚合中所有实体之间数据不一致的问题

领域事件

虽然通过以上这些概念，我们已经可以实现对业务领域的初步建模，但是在实际的业务中，一个业务操作可能需要多个聚合或领域之间协同才能完成，在一个业务操作执行完后，触发另外一个业务操作的行为，就被称作领域事件

领域事件分为微服务内领域事件和微服务外领域事件，微服务内的领域事件通常发生在同一限界上下文下多个聚合之间。微服务间的领域事件会跨越限界上下文进行聚合的协作，通常会使用发布、订阅的消息机制，引入消息中间件，由于会跨越多个服务，因此还会引入分布式一致性的问题。领域事件虽然引入了较大的复杂性，但是切断了领域模型间的强依赖关系，在微服务间使用，可以完成微服务间的解耦，在微服务内使用，虽然也可以达到领域模型间解耦的目的，但这种解耦的收益往往小于引入的复杂性带来的消耗，因此微服务内的领域事件也较少被使用