对DDD的常见误区

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「205」篇原创敬上

大家好，我是Z哥。

我从 2014 年开始接触 DDD 到现在也有 7 年多时间了，在这个期间踩过很多坑，也是自己慢慢从充满疑问，然后一步一步摸索着到如今可以轻松落地 DDD 的地步。

在 2014 年那会，DDD 的社区远不如现在那么繁荣，甚至还有很多鄙视它的声音。因此网上的资料也很少，大部分的知识获取源自两本书《领域驱动设计软件核心复杂性应对之道》和《实现领域驱动设计》。

所以，我的 DDD 之路和现在的很多人可能不太一样，我是沿着一个书本上浓缩后的核心思想，然后自下而上地通过自己的摸滚打爬慢慢构建的知识体系，而现在很多人是照着一些课程中教的偏实践型的知识，自上而下的模仿，然后再根据自己的理解和场景做出调整优化。

最近几年 DDD 一直很火，网上的课程也有很多。但是说实话，DDD 里面的大多数概念还是很晦涩的，没有那种特别清晰规则，可以像代码规范那样明确指导我们如何 coding，什么是好代码，什么是坏代码。

很多小伙伴从我之前在博客园写的 DDD 系列找过来，和我交流 DDD 相关的问题，发现大家对其中的不少概念还存在一些疑惑。或者说，有些概念自己觉得清楚了，但是落地的时候好像又不知道从何下手。

今天我们就来聊聊我收集到的一些大家的困惑，来和大家交流一下我的观点。

/01 DDD 必须要配合微服务一起用？/

这个问题还有另一种问法，“单体应用能用 DDD 吗？”。

先说结论，必须可以，不是微服务也可以用。

我觉得大家之所以形成这个误区背后的逻辑是这样的。因为 DDD 提倡构建领域模型，划定限界上下文，而限界上下文在微服务中恰好能体现为一个单独的Service，看上去是如此的天衣无缝，它们俩是一组黄金搭档，就该一起使用。

其实，在我看来这两者之间的关系并不是搭档关系，而是一种“道”和“术”的关系。DDD 是一种架构设计方法论，而微服务是一种具体的架构设计实践方案。前者是“道”，后者是“术”，符合某一个“道”的“术”从来都不只有一个。

可能你要问了，单体应用怎么用 DDD ？建议你可以尝试用模块的概念来划定限界上下文，并且将不同的模块分别独立一个包，以此达到类似 Service 的隔离效果。剩下的建模工作就没什么不同了。

/02 限界上下文只能通过拆分成独立的 Service 体现？/

这个问题其实在第一点里已经解答了，不用拆分成独立的 Service 也可以体现限界上下文。

如果你存在这个问题的困惑，大概率是你在平时的开发中没有带着「上下文」这个概念去 coding。

因为我们设计的每一个模型，其实都是对现实世界的抽象，而现实世界中的每一个概念都有它所对应的上下文，脱离上下文任何一个词都有歧义。哪怕是相同的一个词在不同的上下文里表达的含义可能不同，比如，售票系统的中的“座位”与设计电影院的规划系统里的“座位”并不是同一个东西。

/03 业务简单的项目不适合 DDD ？/

这个问题其实就类似于，面积小的房子做装修是不是不需要精心设计？只有那些高大上的别墅、甚至是大型场馆才需要精心设计？

我想答案是显而易见的。

不管是简单的项目还是复杂的项目，他们都不影响良好的抽象设计给项目带来的好处。

不过有些人可能纠结的点在于与 DDD 配套的技术框架、基础设施太复杂。我觉得这个想法就有点本末倒置了。不管是什么技术框架、组件，本身只是一种工具。你拿微服务的那套放到一个简单的单体应用里自然会觉得复杂。但是我们相比回到使用传统的三层架构，更应该是要找到，甚至是自己打造更合适的工具。

/04 Entity 的属性字段需要对应数据表吗？/

我认为这个问题的答案首先有一点是确定的，就是：不像三层架构那样，完全一一对应。

因为 Entity 里面可能会嵌套其它的 Entity，以及 ValueObject。所以里面的属性数量大多会比数据表的字段更多。

另外，我觉得这里最关键的问题是，Entity 的唯一标识该如何体现。

是用一个 Guid ？还是直接业务标识？
如果不用 Guid ，那么值对象如果需要持久化的话，该怎么办？

我自己在实践的时候的标准是，尽量只用业务标识，如果必须要用 Guid，确保它是不可修改，甚至是不可见的。因为 Guid 并不是领域知识的一部分，它只是为了解决技术层面问题而引入的一个东西。

/05 Application、DomainService 的区别？/

很多人不重视 DomainService 的设计，其实它非常重要。因为在领域知识中必然存在很多「行为」不属于任何一个 Entity。比如电商领域中的付款这个动作，到底是放在订单的 Entity 上？还是账户的 Entity 上？其实你会发现都不太适合。此时就是 DomainService 出场的时候了，它避免了某些 Entity 承担过多与其无关的业务，导致过于臃肿。

Application 的职责类似于一个调度器，用来调度各个业务。但是它不应该体现具体的细节，业务的细节应该被封装在 Entity、ValueObject 以及 DomainService 中。

有几个小技巧可以判断是否体现了业务。

不要有 if / else 分支逻辑
不要有任何针对 Entity、ValueObject 上属性的读取和修改操作

概括的来说，Application层只做一件事：将输入的CQE（Command、Query、Event），通过调用领域对象进行业务处理，然后将结果组装成 DTO 返回。

/06 防腐层在那一层做？Application层？/

我觉得防腐层应该放在 Infrastructure 层，与 IRepository 的实现 Repository 同层，为了便于区分，你也可以将它单独一个包。

防腐层中的各种 Facade 应该与 Repository 有共同的 IRepository 。因为防腐层背后具体要做的事情就是从其它系统获取数据，这个职责和 Repository 是一致的。Repository 屏蔽了操作数据库的细节，而防腐层屏蔽了对接其它系统的细节。

我们这次就聊这么多。以上 6 个问题都是有多个人同时提到过的问题，我想它们也更具普遍性。

最后我们总结一下。

DDD 必须要配合微服务一起用？不是，微服务只是 DDD 思想的一种实现方式。
限界上下文只能通过拆分成独立的 Service 体现？不是，单体应用中通过「模块」也可以。
业务简单的项目不适合 DDD ？不是，DDD 这个方法论对任何项目都有帮助。
Entity 的属性字段需要对应数据表吗？无法做到一一对应，因为 Entity 可能存在嵌套。
Application、DomainService 的区别？Application不包含业务，仅对业务进行调度。DomainService 实现不属于任何一个 Entity 的方法。
防腐层在那一层做？Application 层？Infrastructure 层，与 IRepository 的实现 Repository 同层。

好了，希望对你有所帮助。

最后再讲个题外话，「六边形架构」和「洋葱架构」在这些年伴随着 DDD 的概念被普及。其实所谓的六边形架构，他们的边就是由 DDD 概念中的防腐层构建的。所谓的洋葱架构，就是在六边形架构的基础上，针对内部业务对象进行建模，而 DDD 就是一种建模思想。