痛点
-
如何分层
-
无领域专家
-
底层数据固定，不想做大的改动
-
值对象、实体、聚合根拆分困难
先说如何分层
先看下六边形架构
如图我将项目分为四层
领域层
-
也是最底层，整个核心的业务逻辑在此封装
-
封装了业务逻辑、定义了领域模型和实体（不对聚合根、值对象、实体做太多的划分）
-
如果业务逻辑设计领域较多，可以封装领域服务
-
此层是面向接口编程，不关注实现
-
数据从哪来，我不管，我就要这样的数据；
-
数据存哪我不管，只要我要的是能能及时给我；
基础设施层
-
主要是领域层接口的实现（可能是DB、redis、接口等）
-
技术组件的封装，比如：统一的鉴权，数据路由等；
-
非功能性需求的封装
-
如果只是单纯的查询，不涉及到业务逻辑，基础设施层可直接让Adapter调用；
应用层
-
负责获取领域的输入（组装成领域的上下文对象）
-
业务的参数的校验
-
调用领域层做业务处理
-
也可以在这一层做一些非业务性的技术指标做个性化监控
适配器层
-
负责将外部的请求适配到应用层
-
以及进入之前的非业务性校验；
-
我理解是将内外部的请求适配到领域模型层；
无领域专家
我们的业务发展多年，产品换了n波人，没人能从讲清楚每一个细节，产品功能往往都是只上不下，随着版本的迭代，这个系统就变成了一个大泥球，改什么都得慎重。
个人总结了一些方式方法：
-
别管以前是什么样的，目前以及以后想要达到什么样的效果；
-
完善流程图、时序图、用例图，是否能覆盖所有的业务场景；
-
顶层设计，我先不管细节，我先把大框架理清楚，然后一层层的往里剥，直到剥不开了，就是我们的原子方法（下图）；
-
这些都做完了，你对系统的理解也就深了一个层次，但是还不够，你还不能算专家，你还要和业务过后续的发展；
-
拉上产品、测试、运营等相关系统方，过梳理出来的流程，一是了解现在的业务痛点，二是了解业务的规划与业务KPI；
-
这个过程中你的通用语言（我理解的通用语言是和业务等达成一致，并不一定要有代码映射）也有初步的沉淀；
-
然后再基于梳理出来的内容，打散，重组，将业务和实现剥离；
底层数据固定，不能做大的改动
重构并不是为了推翻业务，而是为了解决业务的痛点，让业务能轻装上阵，能更简洁、高效的支撑业务，同时也增强扩展性。在重构之前还要考虑无缝切换，往往很多数据层面的东西你是一下子不太好动的。只能通过后续局部改造，将业务和数据结构剥离，逐步重构；
值对象、实体、聚合根拆分困难
-
严格按照DDD的值对象、实体、聚合根拆分，会让你的项目一团糟；
-
在互联网项目中需求迭代变更的速度太快，有时候变更是你无法把控；
那领域模型应该如何设计？
-
领域模型的设计，只关注业务，不要和任何实现挂钩；
-
聚焦在我要做什么，这里面该有什么，不要过度的设计；
-
如无必要请不要增加太多实体；
最后来一个我实现的一个项目结构
参考：
https://github.com/alibaba/COLA
https://blog.csdn.net/significantfrank/article/details/110934799
文章评论