如果你以前听过这个，请阻止我。

一位开发人员进行需求审查，几分钟后说道：“但这就像我们 6 个月前编写的应用程序的一部分。”

领导说：“我们可以重用该代码吗？”

开发人员表示：“我们抽象它比重写它需要更长的时间。它包含该应用程序特有的其他功能。”

没有人笑。我们都参加了这次会议，感到沮丧。企业不明白为什么要花这么长时间来建设。 IT 领导层正在摇头，因为我们无法利用已经构建的内容。开发人员正苦苦挣扎，不得不再次解决同样的问题。

对于我们这些具有软件开发经验和背景的人来说，我们知道这不是它应该如何工作的。分解问题、构建可重用对象、抽象功能层发生了什么？

良好的开发实践被搁置的原因有很多。对业务问题缺乏了解、时间紧迫和预算都是搁置的借口正确设计解决方案。

_领域驱动设计_想要改变这一点。它不是像敏捷那样的方法论，也不是像 RUP（Rational Unified Process）这样的过程。相反，它“提供了用于制定设计决策的实践和术语结构，这些决策集中并加速处理复杂领域的软件项目”。

与所有工具一样，DDD 有时间和地点。但是，当在正确的环境、正确的时间使用并正确应用时，它可以弥合业务和开发人员之间的差距，并提高企业开发的效率。

什么是领域驱动设计？

DDD 是由 Eric Evans 于 2003 年在他的论文中提出的。同名书。在其中，埃文斯概述了一种系统方法来理解复杂的业务问题并将领域模型应用于这些问题以创建有组织且有针对性的解决方案。

当然，其目的是构建更好、更可重用、更具成本效益的软件，特别是面对高度复杂的业务系统。 Evan 的方法使开发人员能够更好地理解业务问题并与业务伙伴更有效地沟通。

它还旨在帮助开发人员更好地缩小问题范围并限制他们正在构建的内容。俗话说，一口吃掉一头大象。但由于软件解决方案和网络计算的发展，这些片段与现代软件架构有关。

随着企业不断采用和适应软件服务，制定一种方法来规划如何将业务需求分解为服务，甚至微服务变得有用和可重复使用的组件。但从服务开始鼓励自下而上的设计。

另一方面，DDD 从顶部开始。它指导团队在解决业务问题之前创建与业务的共同语言。为了了解它是如何做到这一点的，让我们看一下 DDD 的基础知识。

DDD 101

显然，理解领域驱动设计的第一件事是定义领域的含义。

基本上，域就是我们正在讨论的业务领域。它是与所需解决方案相关的业务领域，并帮助您定义和找到您的领域专家。

您是在谈论新的 CRM 吗？您需要销售人员。新的呼叫中心软件？您需要一名呼叫中心经理。新的 CAD 系统？引进一名工程师。

你想要的是一个拥有_商业_了解您试图通过软件实现解决的问题。那是您的领域专家。

但是，在企业与 IT 通信中，人类普遍面临的一个常见问题是确保大家使用相同的语言。这就是 DDD 下一步的用武之地——创建 Evans 所说的_无处不在的语言_。

这将成为参与该项目的每个人的沟通基石。它将定义团队用于讨论项目的语言。它会随着时间的推移、通过反复试验而不断发展和成长。

例如，如果你被要求制造一辆汽车，你可能会想到“跑车”，而产品经理的意思是“家庭轿车”。因此，就本项目和该领域而言，您定义“汽车”意味着“家庭轿车”。

这是一个有点人为的示例，但您可以看到，如果没有适当的定义，将会导致一些代价高昂的麻烦。

一旦每个人都说同一种语言，开发人员就可以将域分解为更小的子域和有界上下文。有界上下文就像一个微型应用程序，有自己的域。

想想电子商务系统。就其本身而言，它是一种环境——人们使用该应用程序进行购物的环境。但是，在这种背景下还存在较小的领域，例如客户信息、支付处理和库存。其中每一个都是一个有界上下文，具有一个域。

领域驱动设计中有更多细节，其中大部分超出了本文的范围，并开始深入探讨更多技术细节。

但上面描述了 DDD 如何开始处理项目中最有可能变得复杂的部分——业务需求是什么以及如何在整个团队中建立理解。

一点一点地分解项目，使团队能够开发高度模块化的代码片段。可重复使用的代码。可以在不颠覆整个系统的情况下重构代码。

对企业的好处

DDD 给企业带来的最大收益来自于高度复杂的应用程序和领域。

首先，由于需要针对通用语言和有界上下文进行建模，整个组织对该领域有了更深入的了解。

企业还创建了一种通用语言，可以在构建解决方案的上下文中使用，但也可以在整个领域和组织中使用。

可以创建更好的代码，因为领域专家是理解问题和解决方案不可或缺的一部分。

由于定义了上下文，该解决方案组织得更好，重点更集中。

企业获得可重复使用的服务，这些服务可以迭代地改进和更改，而无需关闭整个业务系统。

 不是银弹

但 DDD 并不是解决企业中所有问题的灵丹妙药。

首先，对于较小且不太复杂的项目，或者生命周期或对组织有用性有限的项目来说，它可能有点过分了。

虽然构建领域模型本身很有帮助，但它不是 DDD，而只是 DDD 的一部分。
领域模型的构建非常耗时，并且需要 IT 和业务部门的资源。可能来自多个业务部门。

一开始需要付出很多努力来定义域、子域、上下文和通用语言。这意味着组织的前期成本会更高。该投资可能需要数月或数年才能获得回报。

领域驱动设计是一套有效的技术，适用于复杂的企业级软件项目，这些项目将在组织内运行多年。对于愿意尽早投入资源的组织来说，DDD 的原则单独来说是有优点的。但就像举行每日站立会议与实施敏捷不同一样，创建领域地图与遵循 DDD 也不同。

然而，对于那些符合模式的项目，DDD 值得更深入地研究，作为带来更深入理解和更模块化开发的一种手段。