DDD领域驱动设计

极客时间学习笔记

为什么微服务设计的时候需要DDD？

（1）软件架构模式演进的三个阶段：

          第一阶段是单机架构；

          第二阶段是集中式架构；

          第三阶段是分布式微服务架构；

（2）在单机和集中式架构这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。

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

（4）DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

（5）DDD 包括战略设计和战术设计两部分：

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

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

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

（1）通用语言定义上下文含义，限界上下文则定义领域边界，

（2）限界上下文的作用

1、主要是为了消除通用语言在不同领域中的歧义或者说是限制通用语言的使用范围。

2、是划分领域的重要依据

3、通用语言必须与限界上下文配合使用才有意义

（3）实体和值对象都是领域模型的成员，实体是业务唯一性的载体，是个富对象，包含业务逻辑和唯一标识。

（4）值对象是属性的集合，没有唯一标识，只是数据的容器，没有业务逻辑。值对象是实体的一部分，为了简化设计，将部分相关属性抽离成值对象。

（5）如果值对象变动，原来的值对象可以直接丢弃。也可以理解为值对象是当时数据的快照，只是当时的状态。

（6）值对象过多会导致业务的缺失，影响查询性能。具体哪些属性可以作为值对象存在要具体问题具体分析。

（1）贫血模型是指使用的领域对象中只有setter和getter方法，所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层；

（2）充血模型将大多数业务逻辑放在领域实体中实现，实体本身包含了属性和它的业务行为，它在领域模型中就是一个具有业务行为和逻辑的基本业务单元；

（3）实体和值对象两者都经过属性聚类形成，实体有唯一性，值对象没有；

（4）实体着重唯一性和延续性，不在意属性的变化，属性全变了，它还是原来那个它；

（5）值对象着重描述性，对属性的变化很敏感，属性变了，它就不是那个它了。

（1）在微服务内，不是少用领域事件，是少用事件总线。

（2）在DDD中是以聚合为单位进行数据管理的，如果一次操作会修改同一个微服务内的多个聚合的数据。

（3）为了解耦不同聚合，你需要采用分布式事务或者用事件总线两种方式。

（4）事件总线不太方便管理服务和数据的关系，可以用类似saga之类的分布式事务技术。总之需要确保不同聚合的业务规则和数据一致性，尽量减少系统建设复杂度。