DDD领域驱动设计概览

领域驱动设计概览

大问题变成一组小问题

多问题变成同类问题

化整为零

按域拆

逻辑拆

物理拆

各种拆

拆分

用户角度出发

业务单元

模块化

面对复杂问题如何思考

通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

从技术思维主观设计系统  转变为客观描述业务形态

DDD是什么

面向业务

是逻辑层面

对业务领域的划分和整合

DDD

面向物理落地

是实现层面

是对应用的物理形态进行拆分和整合

微服务

面向层面

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

领域模型

划分的区域

DDD的战略设计输出举例

软件过程

DDD VS 微服务

分离技术实现的复杂度

围绕业务概念构造领域模型来控制业务的复杂性

为什要用DDD

建立领域模型

划分领域边界

从业务视角出发

用例分析

场景分析

用户旅程分析

事件风暴

战略设计

从技术实现出发

侧重领域模型的实现

战术设计

如何实现DDD思想

领域是用来限定业务边界和范围的

领域

同一个领域下继续根据业务进行细分，称为子域

子域

域

在事件风暴中，团队中达成共识能够简单清晰的描述业务含义和规则的语言

通用语言

限定通用语言的使用范围

范围中只有聚合和实体

限界上下文(Bound Context)

具有唯一标识符，并且标识符随着生命周期的改变不会变化

基于多个价格配置计算出来的折扣实体

0个

不解释

1对1

权限实体（用户和角色持久化对象）

1对多

客户实体和账户实体存到同一个表中

多对一

和数据库持久化对象的关系

用于展示层

把某个指定页面（或组件）的所有数据封装起来

VO（View Object）

Data Transfer Object，数据传输对象

这个概念来源于J2EE的设计模式

原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载

目前泛指用于展示层与服务层之间的数据传输对象。

DTO

Domain Object

领域对象

就是从现实世界中抽象出来的有形或无形的业务实体。

DO

Persistant Object，持久化对象

它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系

如果持久层是RDB，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

PO

关系转换

ref

在不同层有不同的表现关系

实体

若干个属性的集合

值对象

聚合是一个逻辑概念

领域模型中最底层的边界

由业务和逻辑紧密关联的实体和值对象组合而成

在一个聚合中是由聚合根来管理其所有实体的生命周期

聚合

聚合根本质上是一个实体

一个聚合内只有一个聚合根

聚合根和聚合根之间通过唯一id进行跨聚合联系

聚合根

解决子域之间耦合的重要手段，因为它们提供了一种将领域概念和业务语言转化为代码的方法。

当一个领域事件发生时，它会触发一些操作，这些操作可能会更改系统的状态，也可能会导致其他领域事件的发生。

保证聚合间的数据一致性。当一个聚合根上的操作引发了其他聚合根的变更时，将这些变更作为领域事件发布出去，其他聚合根可以订阅这些事件并更新自己的状态，从而实现最终一致性。替换批量处理。可以作为任务的触发器，例如定时任务、异步任务，避免定时+扫描这类批量处理。实现事件源模式。将所有的领域事件全部存储下来，可以用于恢复聚合的状态，实现事件源模式；也可以用于后续的审计和调试。进行限界上下文集成。将事件从一个子域发布到另一个子域，使得这两个子域可以解耦，不用相互知道彼此的存在。

作用

事件名称

相关数据: 这些数据包含了事件发生时与事件相关的所有信息

发送者-通常是触发事件的对象

接收者-则是事件处理的对象

内容组成

领域事件

领域服务是聚合内部的

主要实现多个实体组合出来的能力

单个实体的功能在实体方法里实现

领域服务

聚合的构建过程

核心名词

传统MVC和DDD四层对应关系

数据对象

接口层

领域服务的编排

权限控制

安全校验

领域事件发布

应用层

DO(Domain Object)

核心业务的实现

领域层

PO(Persistent Object)

接口实现分离

利用仓储设计模式

数据库解耦

基础层

四层分层

层级之间可以互相依赖

松耦合分层

每层只能与位于其下方的层发生耦合

严格分层（推荐使用）

种类

DDD分层

用户接口层-应用层-领域层-基础层

分支主题

分层图

分层协同图

DDD分层模型

同心圆代表软件的不同部分，从里向外依次是领域模型，领域服务，应用服务和外层的基础设施和用户终端。

整洁架构模型（洋葱模型）

将应用分为内六边形和外六边形两层

内六边形实现应用的核心业务逻辑

外六边形完成外部应用、基础资源等的交互和访问。

对于与不同的外部系统交互，由外六边形的适配器负责协议转换，保证内六边形业务逻辑的干净。

内外六边形

图解

分层架构一旦使用依赖倒置、依赖注入的方式，便不属于分层架构，自然就拥有了端口与适配器风格。各个组件的交互完全通过接口完成，而不是具体细节。无论是高层还是底层，都依赖于抽象（因抽象接口都定义在了领域层，看起来领域层已经成为了中心，层次架构已经是内外结构）

在六边形架构中，每条边要么代表客户输入交互的不同端口，通过不同类型的适配器进行适配完成格式协议转换等，从而实现程序内部可理解的输入类型；要么代表通过不同的适配器输出存储实例、向外界发送时间消息等输出类型

六边形架构中的内部六边形代表了应用程序，是一个应用程序的边界。应当根据应用程序的功能需求提供给外部适配器使用，要求使用领域模型来处理请求，并包含业务实现功能。这里我们可以看出，外部适配器可能存在无数个，但应用程序的个数是确定的且是根据业务需求决定的，提倡业务逻辑为关注点（六边形的核心），其余都是可替换的。外部都是可替换的

理论备注

六边形架构 （端口与适配器）

三种架构的区别

微服务架构模型

https://baijiahao.baidu.com/s?id=1776362714515634868&wfr=spider&for=pc