DDD(Domain-Driven Design 领域驱动设计) 初体验

最新推荐文章于 2024-08-27 18:33:58 发布

synuwxy

最新推荐文章于 2024-08-27 18:33:58 发布

阅读量1.8k

点赞数 2

分类专栏：领域驱动设计文章标签： java 经验分享后端 spring

本文链接：https://blog.csdn.net/synuwxy/article/details/115057448

版权

本文介绍了作者初次尝试DDD(Domain-Driven Design)的心得体会。从传统MVC架构出发，经过贫血模型到充血模型的转变，抽离数据库交互，以及引入CQRS，详细描述了DDD改造的过程和遇到的问题。文章讨论了DDD的挑战，如领域划分、团队协作和代码一致性，并提出了应用DDD所需满足的条件。最后，作者认为DDD适合高素质团队，而大型项目常采用MVC架构。

摘要由CSDN通过智能技术生成

DDD(Domain-Driven Design 领域驱动设计) 初体验

DDD (Domain-Driven Design 领域驱动设计) 或许也叫 Dream-Driven Design，某度说这是一种程序的设计思想，使用诸如聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等概念，在领域专家的指引下构造代码。在这种情况下写出的代码具备领域划分明确，响应需求变更快等特点。

但在目前大部分情况下都是用来吹逼的东西，概念虚无缥缈，实践中困难重重。

缘起

因为最近公司业务需要，我从一个只写java的码农需要逐渐转变成一个要写一部分golang的码农。

在熟悉了spring-boot各种封装特性以及刻在骨子里的MVC思想的我开始接触go — 这语法是真的丑

大约爬了2、3天代码，我发现出大问题，似乎没了MVC，就不会写代码了，更恐怖的是我发现正统golang出身的码农眼里似乎根本就没有MVC，他们写代码很多像是放飞自我型，5个人里面可能有6种风格，而我的代码似乎是第7种。

没了MVC，代码感觉失去了灵魂，那么除了MVC，还有什么是可以去指引代码结构的呢？怀着这种疑问，我发现了DDD

尝试

传统MVC结构写代码基本思路和面向过程没太大区别，以典型springboot项目为例，一个接口的调用链大概是这样的

controller -> service -> dao

基本遵循一个A -> B -> C 函数间调度，实体类entity基本都是当做入参来传递。与面向对象3大特性:封装、继承、多态几乎不沾边，写代码如同填空题，只需要往里面填东西就可以了

百度告诉我，DDD基本都采取面向对象的编程思路，在写的过程中要求针对业务对类进行职责分明的封装，并且需要将不同类的领域边界划分清楚，一个类体现的是"业务的高度浓缩"，也就是一个类既具备能力也具备属性。DDD追求的是核心代码使用原生的代码，不依赖任何第三方库或者框架，这样易于维护和迁移。DDD的代码往往采用聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等高大上的手法，可以让我的代码无比完美。

nice

所以我随手拿了一个曾经的crud项目作为样例，开始了改造。

首先第一步，贫血模型改成充血模型

将贫血模型改成充血模型，简单点就是把service和dao这2层合并，将方法和私有成员放在一起，再按照业务重新划分对象边界，把新生的类丢到一个包下面，最后给它取一个名字 — 聚合根

大概就是原来长这样

public class OrderModel {
   
    private Long id;
    ...
}

现在长这样

public class Order {
   
    private Long id;
    ...
    public Long getOrderKey() {
   
      // 此处省略很多拼装逻辑
      return SHA256(id);
    }
    ...
}

将贫血模型改成充血模型之后，面临了2个问题

spring没了，由于聚合根的数据和方法是放在一起的，方法中大量引用自身的数据，导致了大多数情况下，这个类的对象必须现场填入数据构建，这就导致了ioc基本失去了效果
数据校验很麻烦，原来的校验是通过springboot的各种注解统一校验以及ioc的自动注入保证service的引用都有实例存在，每个方法在调用的时候其实是比较放心的。充血模型就有个很奇妙的现象，有些方法其实不会用到所有的成员变量，在很多场景下，一个对象的成员变量是有空缺的，这个时候调用它的其他方法很容易造成NPE等问题，这种问题的出现使得代码不得不在每一个方法内部对它所需要的成员变量进行校验，否则就只能期望调用方自觉不碰雷区了

为了解决这2个问题，我不得不将spring的生存空间压缩到controller层，只用spring封装的request入口，