【领域驱动设计DDD】——初识概念

背景

       随着微服务技术的发展，越来越多的公司开始接入微服务，在微服务的推动过程中，发生了很奇怪的现象，团队没有因为技术方案一筹莫展，反而因为微服务到底应该拆多小而争得面红耳赤，不同的人会根据自己对微服务的理解而拆分出不同的微服务，于是大家各执一词，谁也说服不了谁，都觉得自己很有道理。随着深入的了解，发现服务的拆分是可以有合适的理论或设计方法来指导微服务设计。

      微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。

何为领域驱动设计

       2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD 包括战略设计和战术设计两部分。

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

DDD中概念讲解

1、领域

领域就是这个边界内要解决的业务问题域。

2、子域

是领域的细化，拆分为子域

核心域——业务成功的主要因素和公司的核心竞争力

通用域——没有太多个性化的诉求，同时被多个子域使用的通用功能子域

支撑域——还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域

3、实体

拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致

4、值对象

通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体

它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象

5、聚合

能让实体和值对象协同工作的组织就是聚合

聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

6、聚合根

每个聚合中只能有一个聚合根

它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑

它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。

聚合根在聚合中的作用

聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。

实体可以成为聚合根的判断条件——是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。

DDD与微服务的关系

DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。

用三步来划定领域模型和微服务的边界。

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。 

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

总结

面对复杂问题，解决办法通常是拆分，模块化，化整为零。

领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。

领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。

DDD战略设计得输出，是微服务的输入。