痛点

• 如何分层

• 无领域专家

• 底层数据固定，不想做大的改动

• 值对象、实体、聚合根拆分困难

先说如何分层

先看下六边形架构 

如图我将项目分为四层

领域层

• 也是最底层，整个核心的业务逻辑在此封装

• 封装了业务逻辑、定义了领域模型和实体（不对聚合根、值对象、实体做太多的划分）

• 如果业务逻辑设计领域较多，可以封装领域服务

• 此层是面向接口编程，不关注实现

• 数据从哪来，我不管，我就要这样的数据；

• 数据存哪我不管，只要我要的是能能及时给我；

基础设施层

• 主要是领域层接口的实现（可能是DB、redis、接口等）

• 技术组件的封装，比如：统一的鉴权，数据路由等；

• 非功能性需求的封装

• 如果只是单纯的查询，不涉及到业务逻辑，基础设施层可直接让Adapter调用；

应用层

• 负责获取领域的输入（组装成领域的上下文对象）

• 业务的参数的校验

• 调用领域层做业务处理

• 也可以在这一层做一些非业务性的技术指标做个性化监控

适配器层

• 负责将外部的请求适配到应用层

• 以及进入之前的非业务性校验；

• 我理解是将内外部的请求适配到领域模型层；

无领域专家

我们的业务发展多年，产品换了n波人，没人能从讲清楚每一个细节，产品功能往往都是只上不下，随着版本的迭代，这个系统就变成了一个大泥球，改什么都得慎重。

个人总结了一些方式方法：

• 别管以前是什么样的，目前以及以后想要达到什么样的效果；

• 完善流程图、时序图、用例图，是否能覆盖所有的业务场景；

• 顶层设计，我先不管细节，我先把大框架理清楚，然后一层层的往里剥，直到剥不开了，就是我们的原子方法（下图）；

• 这些都做完了，你对系统的理解也就深了一个层次，但是还不够，你还不能算专家，你还要和业务过后续的发展；

• 拉上产品、测试、运营等相关系统方，过梳理出来的流程，一是了解现在的业务痛点，二是了解业务的规划与业务KPI；

• 这个过程中你的通用语言（我理解的通用语言是和业务等达成一致，并不一定要有代码映射）也有初步的沉淀；

• 然后再基于梳理出来的内容，打散，重组，将业务和实现剥离；

底层数据固定，不能做大的改动

重构并不是为了推翻业务，而是为了解决业务的痛点，让业务能轻装上阵，能更简洁、高效的支撑业务，同时也增强扩展性。在重构之前还要考虑无缝切换，往往很多数据层面的东西你是一下子不太好动的。只能通过后续局部改造，将业务和数据结构剥离，逐步重构；

值对象、实体、聚合根拆分困难

• 严格按照DDD的值对象、实体、聚合根拆分，会让你的项目一团糟；

• 在互联网项目中需求迭代变更的速度太快，有时候变更是你无法把控；

那领域模型应该如何设计？

• 领域模型的设计，只关注业务，不要和任何实现挂钩；

• 聚焦在我要做什么，这里面该有什么，不要过度的设计；

• 如无必要请不要增加太多实体；

最后来一个我实现的一个项目结构 

参考：

https://github.com/alibaba/COLA https://blog.csdn.net/significantfrank/article/details/110934799