解决DDD核心的复杂性

让我们做一个小实验：试着向那些对此毫无头绪的人解释领域驱动设计的要点。这一点，特别是简洁地说，并不容易。哎呀，我自己也在努力。有界的上下文，实体，域事件，值对象，域，聚合，存储库......

为了在明显的混乱中找到顺序，我想从一个相当不同寻常的角度分析DDD方法 - 将领域驱动设计应用于领域驱动设计本身。毕竟，这种方法旨在处理复杂的领域，不是吗？

让我们首先确定核心领域：DDD的主要竞争优势是什么，以及实现它的手段是什么？

核心领域：无所不在的语言

在“领域驱动设计：解决软件核心中的复杂性”（蓝皮书）中，Eric Evans认为领域专家和软件开发团队之间的不良协作导致许多开发工作失败。DDD旨在通过弥合这种协作和沟通差距来提高成功率。

为了能够流畅地分享知识，DDD呼吁培养一种共享的，面向商业的语言：无所不在的语言。此语言应类似于业务域及其术语，实体和流程。

无处不在的语言应该在整个项目中广泛使用。所有沟通都应该在无所不在的语言中进行。所有文件都应在其中制定。甚至代码也应该“说出”无所不在的语言。

许多方法都在努力降低风险并提高软件项目的成功率，但由于Ubiquitous Language统一语言是DDD实现它的手段，我认为它是域驱动设计的核心领域。

定义无所不在的语言并不是一件容易的事。由于软件不能很好地应对歧义，因此每个泛在语言术语应该只具有一个含义。不幸的是，这不是人类语言的工作方式 - 通常语言在不同的语境中具有不同的含义。为克服这一障碍并支持培养严谨语言的过程，采用了另一种DDD模式：有界上下文。

支持子域：有界上下文

为了防止术语具有多重含义，DDD要求每种语言都具有严格的适用性上下文，称为有界上下文。这种模式定义了一个边界，在其中可以自由使用泛在语言。除此之外，语言的术语可能有不同的含义。

虽然有界上下文模式是领域驱动设计的重要组成部分，但我认为它是一个支持子域，因为它的目的是支持无处不在的语言 - 核心域的形成。

正如我之前提到的，代码还应该“说出”实现它的有界上下文的无处不在的语言。但是，如何在代码中实现业务域？实现业务领域没有一刀切的模式。有多种选择，这是我们的下一站。警告：神圣的奶牛即将受到伤害......

通用子域：领域实现

这些模式提供了实现业务域逻辑的不同方法：

1. 事务脚本
2. 活跃记录
3. 领域模型
4. 事件源领域模型

这些模式中的每一个都适合不同级别的域复杂性。您选择的模式应该具有足够的表现力，以便在代码中实现无所不在的语言。至关重要的是要指出这个决定并非一成不变。随着业务的发展和泛在语言的复杂性的增长，实现模式可以升级为更复杂的模式。

上述四种业务领域实现模式是我目前熟悉的模式。

实际上，可能还有其他人，而不是我目前没有意识到的。

未来可能会发明新的。

它们的实现在各种编程范例中有很大不同。

一些最适合某种编程范例，但在其他范例中实现起来很复杂。

考虑到所有这些波动性，它们是领域驱动设计的重要组成部分吗？

由于域驱动设计方法不能涵盖所有业务领域实现模式，因此可以而且应该从其他来源借用这些技术诀窍。例如，Martin Fowler的“企业应用程序架构模式”一书中描述了事务脚本，活动记录甚至域模型。根据定义，依赖“现成”解决方案的能力使它们成为通用子域。是的，甚至是领域模型模式。

领域驱动设计与战术建模模式的分离可能对DDD的可访问性和采用率产生积极而深远的影响。我想详细说明其中的三个：降低DDD的复杂性，扩大其适用性，以及通过跳过微服务的潮流获得大量吸引力的能力。

1.降低复杂性

DDD与战术建模模式的脱钩将防止许多新人经历的许多误解和困难 ，一旦DDD与战术建模模式分离，它就不再需要任何代码样本。它是一种纯系统建模方法，可应用于任何技术堆栈和任何软件范例。

2.更广泛的适用性

我非常不同意领域驱动设计应该只应用于复杂项目的观点。这一概念是由DDD与领域模型模式的强耦合驱动的。一旦我们打破这种耦合，就会开启一个全新的可能性世界。

沟通：

无论业务领域多么简单，如果团队成员对相同的工件使用不同的术语，迟早他们会发现自己处于意外复杂的境界。无所不在的语言模式阻止了这种情况，并在所有团队成员之间产生了清晰的沟通媒介。

业务增长：

领域的复杂性增加的频率高于其复杂性降低的领域。对于所谓的非复杂项目，这种增加的可能性最高。一旦发生这种情况，应重新考虑实施模式决策并使其适应新的复杂性级别。

3.微服务

如今，微服务炙手可热。扩展DDD对更多项目类型的适用性将允许许多基于微服务的解决方案利用宝贵的DDD工具。有界上下文模式提供了一种将系统划分为一组独立服务的业务驱动方式，而结构映射是映射服务的拓扑和它们之间的交互模式的好方法。

“你疯了吗？”

我不认为我的命题 - 从DDD中取出战术模式 - 就像它最初听起来一样疯狂。回到了欧洲DDD会议2016年，Eric Evans的自己说，在蓝皮书中描述的是一种领域模型实现的方式，但许多误以为它是领域驱动设计的实现方式。

看，战术建模模式从来没有打算成为DDD的唯一方式，但很多人都认为它们是这样的。它们会产生外来噪音，并使注意力从最重要且独特的DDD特点上移开。

此外，您不能说领域驱动设计方法处于完美状态，并且没有理由改变。不幸的是，它的低采用率不言自明。DDD值得更多关注。蓝皮书十多年前就出版了，从那时起，这种方法几乎没有改变。我相信它应该改变。不是因为它很糟糕 - 恰恰相反，因为它很棒。但它具有比目前实现的更多，更多的潜力。

最后的想法

我决不打算诋毁战术建模的重要性。恰恰相反：这个主题值得关注得多。但在它自己的背景下。除了领域模型之外，还有更多的模式，以及更多的方法来实现它们，而不是适合单个DDD书籍。而且，即使在非DDD项目中也可以实现这些模式，即使项目中没有单一的聚合，项目也可以遵循DDD原则。