DDD领域设计过程

DDD领域设计过程

读完《中台架构与实现：基于DDD和微服务》后发现这是有本是很实用的DDD落地的书，
里面有详细的基础概念的讲解，浅显易懂，针对每个DDD落地步骤的写的很清楚，从战略设计到
落地代码的战术设计，非常推荐，读后基于自己这本书的理解，整理下自己对领域开发过程以demo的形式来回顾下，加深自己的理解

领域设计目的：

1. 标准的代码模型可以想团队成员更好的理解代码，根据统一的代码规范实现团队协作
2. 微服务各层业务逻辑互不干扰，各层之间互相解藕，避免不必要的业务杂揉
3. 各个业务划分清晰后，业务owenr可以更好明确维护自己负责业务

战略设计

公司发现很多没有技术能力的传统企业用户，想做用户留存，做客户活跃，保持客户对他们产品的粘性提升gmv，所以想把把积分作为用户留存的手段，决定要做一款营销工具，但是投入技术成本较高，要养一批开发，后续运维成本也高，不一定能做出好的一款活跃用户的营销产品，所以抓住了这个市场，利用专业能力打造一款saas营销工具—积分商城

积分商城做打入saas市场的重要产品，需要确认它是一款什么样的产品，具体哪些功能，传达的价值主张是什么

总结汇总：

为了帮助缺乏线上营销手段的客户，提升客户积分消耗，客户留存，我们提供的产品是可以支持客户以订阅方式使用的一款saas营销工具，可以帮助客户进行线上优质商品售卖，积分支付，他不是一个电商平台，他是一款营销平台

事件风暴梳理业务

识别业务数据，业务行为（用例）

划分领域，定义各个业务模块之间的边界

根据划分好的领域模块。整理下模块与具体功能

战术设计

如何设计让业务模块设计跟代码模型结构一致

系统分层

代码结构改变如下

用户接口层（对标的在web层里面的一个接口，采用门面模式，解偶后端实现）

1. assemble 实现DTO与Do对象之间的交互转换合数据交互
2. dto 前端应用数据传输的载体
3. facade 封装应用服务，提供粗粒度的调用接口

应用层（对标的是现在web层）

1. event 存放事件相关的代码
   1. publish 事件发布相关
   2. subscribe 事件订阅相关
2. service 应用服务队多个领域服务或其他为服务的应用服务进行封装，编排，组合，对外提供粗粒度的服务能力

领域层（对标现在的center层）

aggregate（聚合）可以命名为具体业务的实体名称，里面分别为具体聚合业务的专属类信息

1. entity 存放聚合类，实体，值对象等
2. event 事件实体，事件相关的业务代码
3. repository 完成聚合类中相关对象的持久化
4. service 该领域对外提供的能力

infrastructure基础层（对标现在的center层）

1. config 配置相关的代码
2. util 工具包等

具体系统内代码结构模型

数据状态的转换流程图

参考书籍：中台架构与实现

参考git：https://gitee.com/kaitoShy/leave-demo.git