领域驱动设计（DDD） 是什么？

DDD 是 Domain-Driven Design 的缩写，中文翻译为领域驱动设计。DDD 是一种软件设计的方法论，最早由 Eric Evans 在 2002 年提出，出自书《领域驱动设计：软件核心复杂性应对之道》。

DDD 核心方法论是什么？

DDD 的核心方法论，简述下来是：领域问题驱动模型设计，模型驱动软件设计。要从领域问题出发，去设计一个领域模型，来解决领域问题，再设计具体的软件来实现这个领域模型，从而得到一个可以解决领域问题的软件系统 。

DDD 有什么优势？

DDD 给对领域不熟悉的新手，对软件设计不熟悉的新手，提供了一种普遍有效的可以快速上手的软件设计方法。

DDD 从领域问题出发的思想，让程序员更关注领域问题，从而更容易开发出能解决领域问题，带来用户价值的软件。DDD 要求有专门实现领域模型的程序模块，作为程序的核心，这让程序去用领域的语言表达如何解决领域问题，从而提升了整个软件的可理解性和可维护性。

DDD 推荐的实践方式，比如领域事件、六边形架构、CQRS 等，也能帮助构建出容易扩展，高性能的软件系统。

如何评判一个项目是否使用了 DDD？

一个项目只要满足以下两个条件，就算是采用了 DDD：

• 遵循了 DDD 核心方法论
• 有单独的模块来实现领域模型

什么是领域？

领域是英文单词 domain 的中文翻译。领域的原意是范围。在 DDD 中，领域指的就是软件系统要解决的问题的范围，或者说有哪些问题需要软件系统来解决。这些问题的解决对于软件系统的用户来说是有价值的，是用户真正关注的。DDD 的方法论，要程序员们把用户真正关注的问题放到第一位，而不是具体的技术实现放到第一位。

很多时候，我们还会说业务、业务领域、业务问题等，这里的业务也是领域的意思。

领域模型是什么？

领域模型是针对领域问题设计的模型。它是领域问题的解决方案，同时它忽略了很多技术实现细节。

有哪些错误的 DDD 实践？

• 不建模，只按照所谓“DDD 规范”去照抄一个 DDD 代码的形式，导致开发成本上升，却享受不到领域模型带来的好处
• 空谈建模，不用代码实现，不会代码实现，导致建模和实现脱节，建模成了“邀功”“忽悠领导”“故弄玄虚”的工具
• 一开始不用 DDD，等项目病入膏肓，已成屎山代码，才想要用 DDD 搞重构，多半是搞不成还让 DDD 背锅。

只有复杂项目才需要用 DDD，简单项目不需要 DDD？

建议只要是需要长期维护的项目，不管是否简单，都从一开始就采用 DDD。

• 在现代建模方法论和开发框架的支持下，实施 DDD 的成本已经不比不采用 DDD 高，甚至初次开发成本也更低于不采用 DDD 了
• 一个开始很简单的项目，在长期维护中，很可能变得越来越复杂。但是没有人知道或者有勇气在项目上线后进行“DDD 重构”，即使真有人做了，也不一定成功。因此不如一开始就采用 DDD。
• 开发人员总是容易一开始低估业务的复杂性，总以为似乎都是 crud。随着开发的深入，才会发现越来越多隐藏的业务逻辑。不如一开始就采用 DDD，深入挖掘业务逻辑。