DDD-领域驱动设计重构的痛点及项目结构的划分

Posted 鱼翔空

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DDD-领域驱动设计重构的痛点及项目结构的划分相关的知识,希望对你有一定的参考价值。

痛点

  • 如何分层

  • 无领域专家

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

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

先说如何分层

先看下六边形架构

如图我将项目分为四层

在这里插入图片描述

领域层

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

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

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

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

  • 数据从哪来,我不管,我就要这样的数据;

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

基础设施层

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

  • 技术组件的封装,比如:统一的鉴权,数据路由等;

  • 非功能性需求的封装

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

应用层

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

  • 业务的参数的校验

  • 调用领域层做业务处理

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

适配器层

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

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

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

无领域专家

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考:

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

如果觉得对你有帮助,请关注公众号:5ycode,后续会不断更新哦

公众号图片

以上是关于DDD-领域驱动设计重构的痛点及项目结构的划分的主要内容,如果未能解决你的问题,请参考以下文章

DDD领域驱动设计落地实践系列:初识DDD

DDD领域驱动设计精要

领域驱动设计(DDD)中简单易用的10种技巧

《领域驱动设计》读书笔记

领域驱动设计(DDD)的几种典型架构介绍

DDD领域驱动设计实战-分层架构及代码目录结构