DDD的思想内核

用过DDD的同学会知道，自己用倒没什么，一旦到了要推广部门内使用的时候就会非常困难。为什么会这样？做为一个有8年DDD实战经验的过来人，我想尝试分析一下原因：

1. 过多的概念让人望而生畏，这也是DDD饱受诟病的地方，在推广DDD的过程中我不止一次听到“DDD太复杂了，在我们这里没法落地”。
2. 也是由于初始学习曲线过于陡峭，大部分人其实处于“懂”和“不懂”中间，这其实很可怕，人们在引入DDD的时候会只引入容易理解的部分，忽略掉自认为“没啥用”的部分，最后导致既没达到想要的效果又增加了复杂度，然后得出一个结论：DDD我用过，不好用
3. 思维惯性

和怕承担风险。人是倾向于使用已有的知识结构去解决问题的，用简单的分层架构

1. ，加一些存储和中间件，不用DDD好像也能解决问题。“又不是不能用”，大家都不愿意冒着风险引入一些新东西。

行吧，那我们姑且撇开那些枯燥的概念，只一篇文章也聊不明白（当然我也得假设你至少听说过这些概念，否则你不会点进来看这篇文章）。接下来我们就只探讨DDD的思想内核，或许能稍稍降低一些理解门槛，尽量让大家明白“哦，原来DDD是干这个的！”

DDD的内核是什么

那么DDD的内核是什么呢？

1. 指导写代码？显然不准确，格局低了一些。
2. 指导做架构设计

1. ？说对了一半，没讲到精髓。

先来看一张架构图示例：

这是现在很典型的一种架构分层

，横向先根据不同技术领域先分几层，大差不差也不会有什么人挑战。问题出在应用层和微服务层，实际上很少人能说清这两层分类的标准是什么？高内聚低耦合吗？就是这句看起来说了但又什么都没说的话在指导着架构设计。有没有更靠谱一点的方法论？这就是DDD想说的第一件事，它提供了一种给“应用层

”或“服务层”分类的方法。

接下来DDD想告诉你第二件事：保护好你的代码边界，否则它会变得腐化且难以维护。这句看起来理所当然的话事实上并没有那么容易做到，首先“边界”并不那么好界定，其次为了守住边界就得立一些规范，有时候为了赶项目进度，边界是可以模糊的，要知道一旦模糊了以后再想规范起来可就没那么容易了。

保护好边界后，面对边界内的核心代码，接下来就是DDD想说的第三件事：让模型回归业务的本质。

以上就是DDD内核的全部内容，接下来我想调换一下顺序，先聊一聊看起来最抽象的第三件事。

问题空间

和解空间

正式开始之前，我想先聊一聊问题空间和解空间。

问一个问题，把小球向斜上方30°以3m/s的速度扔出，小球多久能落地？小球落地时扔了多远？ 这是一道初中物理题，为了解这个问题，我们需要进行建模，忽略空气阻力的情况下小球会呈抛物线运动，结合三角函数和动力学方程

，很容易能得出问题的解。（没算错的话大约是0.2s，扔的距离大约是0.4m）

可以看到问题空间到解空间的过程需要经过一些抽象，”抛物线“就是一个抽象，我们还要忽略空气阻力，暂不考虑扔球者的身高，合理的建模就能得到问题的解。然而解空间

永远不可能等同于问题空间，只可能无限接近。比如你无法模拟出小球运行过程中的空气阻力，也不会为了算一道题就去测量常量g的数值，一般取9.8m/s²。

如果解空间的建模与问题空间相差较大（上右图），也就是说引入了问题空间以外的因素，例如抛球时人手心有没有冒汗，当天的空气湿度之类的。也许问题依然可解，但那会凭空增加许多复杂度。

让模型回归业务本质

在软件领域，问题空间就是业务规则，解空间就是你所建立的系统，你通过建立系统把这个世界的一部分规则通过数字化的方式运行起来。我们理想的方式是解空间是问题空间的一个子集，尽量不引入问题空间以外的因素，这就是让模型回归业务本质的含义。

怎样才能回归本质呢？DDD说要对领域进行建模，所谓的领域（Domain），大白话就是业务规则和业务概念，领域模型

就是业务规则的集合。完整的领域模型应该是要包含服务（Service）、事件（Event）和实体（Entity）、DP（约等于ValueObject）等

1. 服务说的是接口和流程
2. 事件说的是状态变化或执行结果
3. 实体和值对象是领域对象的载体

建模的过程大家应该不陌生，就是用UML工具把上面这些东西画出来，现在问题在于怎样让模型更接近业务的本质？DDD提供了一些方法和辅助工具：

1. 让领域专家参与建模（对这个业务最了解的人）
2. 建立统一语言（Ubiquitous Language），消除认知差异
3. 用业务行为来描述接口，不要用技术概念。以账户为例，开户、销户、冻结、解冻、修改注册信息、修改支付限额等都是业务行为，增删改查