领域驱动模型（DDD）学习笔记

领域驱动的核心思想

将对软件的分析和设计还原到真实的客观世界中。

一个复杂系统的领域驱动设计，是以子域为中心进行领域建模绘制出一张一张的领域模型设计。

DDD的真谛

领域建模，即深入理解业务。

设计思路

• 贫血模型
  在软件设计中，POJO对象中，他们只有get/set 方法，没有业务逻辑。
• 充血模型
  在软件设计中，POJO对象中，他们只有get/set 方法，有业务逻辑。

两种设计思路的优劣比较：

充血模型：

保持了对象的封装性，使得领域模型在面临多态，继承等复杂结构时，易于变更。
保持了领域模型的原貌，需求变更可以直接映射成程序变更。
需要开发人员需要更高的分析业务、业务建模与设计能力。

贫血模型：

更加容易应对复杂的业务处理场景
将复杂的业务处理场景，划分为多个相对独立的步骤，然后交给多个service串联执行。

聚合的设计思路：

聚合体现的是一种整体与部分的关系，对比数据库中的一对多的关系，比如订单和订单明细的关系。
一个订单对象中包含了多条订单明细，并且将他们做成了一个聚合。

仓库

采用仓库的概念完成对数据库的访问。

工厂

是领域对象生命周期的起点。
比如：系统要通过id装载（查询）一个订单对象

• 订单仓库将任务交个订单工厂，订单工厂分别调用订单dao，订单明细dao和用户dao去查询。
• 将订单明细对象和用户对象，分别set到订单对象的订单明细和用户属性中。
• 订单工厂将装配好的订单对象返回给订单仓库。

DDD 是如何解决微服务拆分的？

微服务拆分原则：

• 高内聚：就是单一职责原则，将代码修改的范围缩小到这个微服务内。
• 低耦合：具体可通过接口调用其他服务。

架构师需要的能力：

• 能够将业务转换为技术，将业务需求落地到技术方案。

• 能合理利用技术支撑业务。