领域驱动设计-基本概念（一）

一、关于DDD？

（1）是什么：一种处理高度复杂领域的设计思想；不是架构，而是一种架构设计方法论。

（2）要解决什么：

         a、试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解、难以演进的问题

         b、通过边界划分将复杂业务领域简化，设计出清晰的领域和应用边界，可以很容易的实现架构演进

        c、应用：微服务设计和拆分；中台业务模型

二、组成部分：战略设计、战术设计

战略设计：从业务视角出发，建立领域模型、划分领域边界，建立通用语言的限界上下文

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

三、如何进行战略设计？

（1）怎么做：建立领域模型（可以用于指导微服务的设计和拆分） -> 划分领域边界  -> 建立通用语言的界限上下文（作为微服务设计的参考边界）

（2）建立领域模型的方法：事件风暴（包括三种方式：用例分析、场景分析、用户旅程分析）

注意： a、 事件风暴是一个发散到收敛的过程，

            b、采用上述三种方式，分解业务领域、梳理领域对象之间的关系，这是发散的过程

            b、 事件风暴过程中会产生很多的实体、命令、事件等领域对象，将这些从不同的纬度进行聚类，形成聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程

四、三步划定领域模型和微服务的边界：

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

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

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

在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。

五、DDD与微服务的关系

DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

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

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