领域驱动设计：为什么企业需要这种方法，谁在使用它，以及它的本质是什么？

在一个动态且不断变化的技术世界中，构建满足企业和用户需求与期望的软件可能是具有挑战性的。软件公司逐渐需要一种可行的方式来使业务与产品团队之间的沟通更加透明。领域驱动设计（DDD）方法通过促进对主题内容的深刻理解和开发人员与业务专家之间的持续合作，帮助解决这个问题。实际上，开发者通过不断的沟通获得了对底层领域和业务规则更深入的理解。与此同时，利益相关者对技术能力和限制有了更好的理解。

例如，Standish Group 对 100 个项目的分析发现，因为在需求和设计阶段缺乏领域知识，70% 的返工产生了，这证实了 DDD 促进了企业与开发者之间的理解。

根据 Forrester 的数据，实践迭代式 DDD 模型的开发团队的工作速度比他们在前期分析上花费数月时间快 60%。

由剑桥大学进行的研究发现，在 DDD 框架内建模领域知识可以使团队生产力增加 29%。显然，这种方法解锁了内部领域知识。

那么，为什么公司需要这种方法，谁在使用它，以及它的本质是什么呢？

领域驱动设计的核心原则

领域中心设计基于几个关键概念，这些概念使得创建以领域为中心的软件成为可能。

• 首先是对领域模型的优先考虑。它代表了潜在的商业实体、行为、关系和规则。代码实现直接反映领域模型，而不是相反。这个模型是迭代开发的，而不是预先确定的。
• 另一个核心原则是开发一种普遍语言。这种开发人员和业务专家共享的词汇标准化了术语和领域知识，消除了团队间的歧义和不一致。
• DDD 还包括战略和战术设计阶段。战略设计关注于领域的高层组织，如限界上下文和子领域。战术设计涵盖了模式和较低层级的实现组件，如实体、服务和仓储。

其他概念包括强调探索性建模而不是分析，持续的领域沉浸，以及使用普遍语言进行文档化。

通过结合建模、语言和基于上下文的技术，DDD 使得创建的系统不仅关注技术要求，还关注领域的核心概念。

在这个背景下，立即想到的是六边形架构和干净架构，它们共享任务分离的共同目标。你可以通过将应用程序划分为松散耦合的组件，从外部问题中隔离核心业务逻辑。

让我们来看看定义战略和战术设计的元素，以及它们如何影响结果。

战略设计

在 DDD 的背景下，战略设计是软件开发的一个重要部分。它包括以下主要方面：

• 概览： 战略设计始于对问题领域和商业价值的概览。在这一步，将探索关键概念和流程，并识别关键商业需求和目标。
• 问题空间和解决方案空间： 战略设计框架识别出两个主要的概念空间：问题空间和解决方案空间。问题空间关注于探索和分析业务领域，识别实体、聚合、服务以及它们之间的关系。解决方案空间则关注于创建一个有效解决问题空间中识别出的问题的模型。
• 限界上下文： 限界上下文是领域的有限子划分，对应于特定开发团队的责任领域。每个上下文定义其实体、聚合、服务和规则。管理上下文边界对于隔离和理解领域的不同部分至关重要。
• 核心领域： 核心领域是业务的核心，它是最重要和最有价值的部分。在战略设计中，核心领域至关重要，因为它是开发的焦点，并包含定义软件功能的基本抽象和业务规则。

战略设计在 DDD 的背景下，使得通过考虑业务领域的特点来创建软件开发的有效策略成为可能。这帮助开发者创建满足业务要求、灵活规模化和随着时间的推移容易维护的软件。

战术设计

战术设计是软件开发方法论的一部分。它负责一系列定义的工具和方法，用以创建高效、灵活的架构，这些架构反映了业务领域，并确保数据完整性。

1. 它从对业务领域及其要求的概述开始。这一步分析了核心流程、实体、聚合以及它们之间的关系。目标是对领域的核心组件有更深入的理解。
2. 接下来，我们关注应用程序的核心部分，也被称为核心聚合。核心聚合是主要的交互元素，包含了领域的关键逻辑和数据完整性。它定义了核心操作和业务规则。
3. 继续讨论战术设计工具包，它为我们提供了一组规则和模式，用以构建有效的应用程序架构。它包括值对象、实体、服务和聚合等概念。这个工具包帮助开发者创建一个敏捷的架构。
4. 使用战术设计工具包的一个例子是创建仓库。仓库负责存储和检索特定实体或聚合的数据。它们为与数据仓库的交互提供了一个单一的接口，并封装了数据存储细节。

战术设计还区分了应用服务和领域服务。应用服务协调应用程序内不同实体和聚合之间的行动和交互。至于领域服务，它们存储业务逻辑和只与领域模型相关的操作执行。

总而言之，战术设计有助于创建反映业务领域并保证数据完整性的有效架构。使用战术设计工具简化了应用程序的开发和支持，使理解和扩展复杂领域变得更容易。

有界上下文和普遍语言：它们在DDD中的作用

在领域驱动设计中，有界上下文是在特定业务领域内应用的一组模型和规则的集合。它有助于在特定上下文中界定和限制系统的不同方面。

有界上下文代表了开发发生的边界，并确保在该上下文内模型和规则的一致性。因此，它可以拥有自己的建模语言甚至是特定业务领域的术语。

它允许开发者更好地理解和建模一个复杂的主题领域，并促进利益相关者的沟通。有限的上下文可以并行存在，并通过定义的接口进行交互。

同样重要的概念是当我们谈论领域驱动设计时，不可忽视的普遍语言。

它可以被描述为所有开发团队成员使用和理解的通用语言。

普遍语言在有限的上下文内创建和维护。它包括专业术语、短语和规则，这些都反映了系统的业务理解和主题。这种语言作为一个熟悉的基础，便于不同团队成员之间的有效沟通。

它的主要任务是帮助避免由于术语或概念的不同解释和理解而引起的误解，并在某种意义上有助于更深入、更准确地建模主题领域。

DDD带来的新解决方案的钥匙：它带来了什么，以及它适用于谁？

如果一个项目涉及复杂的业务逻辑、不断变化的流程、关系和业务规则，它就成了实施领域驱动设计原则的理想候选者。通过应用DDD，开发者可以有效地导航复杂的领域，并创建精确反映现实世界复杂性的软件解决方案。

DDD还高度适应并灵活应对未来的变化。随着业务的演变和面临新的挑战，软件解决方案必须跟上步伐。有限上下文的清晰分离和普遍语言的使用，促进了更新和修改的无缝整合，最小化了需要进行系统范围内大规模变更的需求。其结果是平滑的过渡，减少的压力水平，以及公司的成本节省。

领域驱动设计的小团队力量

领域驱动设计非常适合小型、自治的团队。"两个披萨团队"的概念就是一个例证。这个想法是团队应该足够小，以至于只需要两个披萨就能喂饱。这使得团队能够集中精力、保持一致并提高生产力。

我们看到"两个披萨团队"的方法与DDD结合，在Netflix（这让他们能够快速扩展平台）和Uber（他们能够灵活地隔离事件并管理需求波动）等行业领袖中成功应用。

看起来，DDD就像一个独家俱乐部，成员包括Netflix、Uber以及我们谦逊的WebLab技术。我们处在一个好公司中，不是吗？

是的，我们使用DDD作为开发复杂业务软件的主要方法之一。看起来我们是少数使用它的公司之一。

有人在DEV社区门户网站上创建了一个讨论："我们如何找到遵循领域驱动设计方法的公司？"

要找到DDD的实践者，跟随良好结构化的对话的踪迹......或者只是找我们的团队！

但有人决定建议，如果他们在提案中提到他们与DDD一起工作，你可以找到这样的公司。需求在那里，但供给并不多。

正如你所看到的，小型、紧密团队在复杂领域中扮演着关键角色。他们可以快速积累知识，并普遍使用他们领域的语言。

对于采用DDD的公司来说，拥抱两个披萨团队的范式能够在各个领域释放生产力和创新。小团队和领域驱动设计的结合是强大的。

特别是，DDD能够实现：

• 改善沟通： 普遍语言允许开发人员和业务专家更有效地合作。
• 业务一致性： 软件设计直接反映真实的业务流程和目标。 灵活性：模块化架构使得根据需求变更应用程序变得容易。
• 用户关注： 关注领域允许创建针对用户需求的定制解决方案。
• 效率： 密切参与的主题专家产出解决实际业务问题的产品。

DDD和小型组织：可能的挑战

在较小的组织中，DDD的整合可能不像在大公司那样普遍。然而，整合的能力取决于特定需求和优先级。如果一个小组织拥有复杂的主题领域或面临有效管理和建模业务流程的需求，DDD的整合可能是有益的。

但是，请准备面对可能出现的障碍，包括：

• 资源有限：较小的组织可能拥有有限的开发人员和时间，这使得实施新方法变得具有挑战性。
• 在主题建模方面的困难：DDD的整合需要对主题领域有深入理解并正确建模。缺乏软件开发经验可能是一个障碍。
• 抵制改变：较小的组织可能更倾向于抵制改变，特别是如果现有流程和软件架构已经确立。
• 技术限制：过时的技术基础设施不支持完全的DDD整合。 事实上，并不是所有这

些障碍都适用于所有小型组织。每个组织都有其独特的特征和挑战，这些都可能影响到DDD的整合。

DDD实施：逐步开始

现在，让我们来看看有效实施DDD的基本步骤，而不被复杂性所迷惑。

从小做起

特别是在刚接触DDD或处理大型系统时，从小开始使用DDD是明智的。选择应用程序中一个小的、不太关键的部分，开始应用DDD。

持续学习

通常，第一次实施可能不会完美。这是一个持续学习的过程。不要因为最初的挑战而气馁。理解错误并从中学习。

合作

DDD不仅仅是关于编码者。它涉及到整个团队：开发者、项目经理、系统分析师、领域专家等。它要求紧密合作，以便根据业务需求进行知识共享和软件开发。

最后，正如我们之前说过的，必须记住，DDD并不总是所有项目的解决方案。它引入的复杂性对于简单的应用程序来说可能是不必要的，评估其在项目中的需求至关重要。

交点：DDD与敏捷的连接

那么，DDD与敏捷的交集是如何体现的呢？DDD和敏捷分享类似的原则，为它们成功的整合奠定了基础。

1. 与利益相关者的积极互动： 在DDD中，这反映在普遍使用促进有效沟通的语言中，而敏捷则侧重于合作以创造价值。
2. 灵活性和适应性： 两种方法论都是可适应的。敏捷设计用来接受和实施变更，而DDD模型则随着领域理解的演变而演变。
3. 迭代开发： 敏捷专注于小步骤进行软件开发。在DDD中，模型随着演进而精细化，这又把我们带回到DDD的迭代本质。

DDD与敏捷的连接本身就是一种互补关系。因此，在敏捷环境中使用DDD可以简化沟通，确保更好地与业务需求对齐，并交付高质量的软件。

我们可以自信地说，依赖于领域知识的行业在DDD专注于学习其特定领域的复杂性上找到了特别的价值。最终，领域中心设计的本质在于它能够创建与业务及其客户需求紧密对齐的高质量软件。

对于WebLab技术来说，DDD方法是我们构建与客户长期技术合作伙伴关系的意识形态的核心部分。它与康威定律相一致，该定律指出，软件系统反映了构建它们的组织的通信结构。

我们的专业团队创建与客户领域自然契合的架构，而领域专家的深入参与使我们能够创建一个涉及所有人的顺畅通信链。或许越来越多的公司意识到这种方法的需要，将来会发现更多有价值的DDD好处。

毕竟，正如Eric Evans在他的书中所写的，"为了有效沟通，代码必须基于用来编写需求的相同语言------这同样是开发人员彼此以及与领域专家交流的语言。"这强调了通用语言在DDD中的核心地位，确保所有利益相关者都能够在相同的概念框架内有效沟通。

作者：Oleksandr Knyga

更多技术干货请关注公号【云原生数据库】

squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。