浅谈针对DDD的疑问梳理

前言

前段时间分享过一篇自己有关于DDD与阿里框架Cola的学习与思考：juejin.cn/post/705966…

发现有很多同学再阅读完后还是会有一些对DDD的疑问，今天我主要针对大家的疑问梳理一片文章，希望有助于大家更好的理解。

一、不要为了DDD而DDD

DDD的思想其实从最开始提出到现在已经有很多年了，但是还是有大部分公司的项目并没有采用DDD去进行设计。到底怎么样一个项目应该去进行DDD的重构改造？ 本人谈一下自己的一些理解

1.1 为什么要有DDD？

其实对于我们开发人员来说：每一个人都希望自己的代码简明易懂，可是经过长时间的迭代，代码可能就随着功能的增多变的越来越复杂。

• 对新同学不友好：复杂的代码逻辑对于新入职的同学来说理解起来会很吃力。
• 多团队协同问题：业务系统边界划分不清，系统间依赖复杂。 可能有很多同学经历过一个问题：一个需求的边界问题，就可能需要一下午的会议去沟通拉齐。那么为什么不同统一语言进行领域的建模、让技术同学与业务同学都能理解一致！
• 缺乏灵活扩展：如果针对频繁变动的复杂系统而言：如何做到场景的灵活扩展、复杂系统下的架构调整？

其实以上都是一个复杂业务系统存在的问题，本人也是简单的进行列举

1.2 DDD的好处又在哪？

• 面向业务领域模型编程

用代码实现系统的聚合与沉淀：日常的业务代码不会对业务知识做更好的沉淀，因为业务知识到处都存在，存在于util、模型、各种service、甚至配置中；这样会导致自己系统的代码后期维护成本很高。 业务代码分散在系统的各个角落，没有做好高内聚、低耦合。

• 统一的开发设计思想

DDD提供了一种统一的设计和开发理念：团队同学会在有界的领域模型上下文中有意识的形成统一语言，便于沟通，减少分歧

• 关注点分离

构建领域模型：将领域模型与数据模型分离，业务复杂度与技术复杂度分离，保持系统代码的结构清晰，以便应对扩展等挑战。

1.3 什么样的系统适合DDD?

其实说到这里，大家心里应该也会有自己的一些认知了，如果一个系统已经变的很复杂，维护成本很高，那么是不是可以考虑进行DDD的重构？

如果一些简单逻辑的项目，例如一些C端项目其实项目内部逻辑并没有非常复杂，更多的只是读服务、进行系统间的调用，那么是不是就可以不用采用DDD。

当然这也只是作者我自己的观点，具体问题还是得具体分析。

二、理解DDD的核心切入点

我看很多同学有疑问说：

很多同学都在担心，如何一个团队的同学自己对领域的理解不一致，那么会不会在长期的迭代过程下代码还是会混乱。

2.1 DDD的核心切入点

• 通用的开发理念与语言

针对上述问题，不同的同学在开发时有不同的观点是很正常的，对业务理解的深浅也是不同的。 但是团队统一标准是DDD开发很重要的一点，通用语言是提炼领域知识的产出物，获得统一语言就是需求分析的过程，也是理解领域知识的过程。在这一过程中，开发同学、团队TL，以及产品经理、领域架构师等等都是要参与进去，并且得到一个统一的答案。

- 比如：老同学带新同学更快地熟悉业务、熟悉领域模型，避免日后开发进入误区
- 一个新需求的分析：团队以及技术负责人先确定在哪一个领域开发，再进行具体的技术细分
复制代码

• 领域

领域是DDD设计的核心。如何确定领域的划分以及领域模型的构建？在充分理解业务的前提下去做好领域的划分。当然在进行这一系列的改造过程中，我们不能忘了改造的本心：降低业务复杂性与理解程度。在领域划分中，也可以细分：核心领域(交易、订单等等)、通用领域(统一权限、没有太大个性化的诉求)等等

• 边界上下文

在领域的设计中，这个也是非常重要的，说简单就是防腐层的处理,既要保证领域业务逻辑之间的隔离性，也要做到领域之间的交互。处理好收口位置，都是在边界上下文需要考虑的。

2.2 设计方式的改变

传统的系统设计可能更多依赖于面向数据驱动开发。但是DDD中，要做到领域模型与数据模型的解耦。

因此在进行DDD项目的改造时，一定要先改变原有以数据驱动为主导的固化思想，先设计出领域模型才是最首要的。