例如，Standish Group对 100 个项目的分析发现，70% 的返工是由于需求和设计阶段缺乏领域知识造成的，这证实了 DDD 促进了企业和开发人员之间的理解。
据Forrester称，实践迭代 DDD 模型的开发团队比花费数月进行前期分析的工作速度快 60%。
剑桥大学进行的研究发现，在 DDD 框架内对领域知识进行建模可以使团队生产力提高 29%。显然，这种方法解锁了内部领域知识。
那么为什么企业需要这种方法，谁使用它，它的本质是什么？
领域驱动设计的核心原则
以领域为中心的设计基于几个关键概念，这些概念支持创建以领域为中心的软件。
● 首先是领域模型的优先级。它代表底层的业务实体、行为、关系和规则。代码实现直接反映领域模型，而不是相反。该模型是迭代开发的，而不是提前预定的。
● 另一个核心原则是开发一种通用语言。开发人员和业务专家的共享词汇标准化了术语和领域知识，消除了团队之间的歧义和不一致。
● DDD 还包括战略和战术设计阶段。战略设计侧重于作为有界上下文和子区域的领域的高层组织。战术设计包含模式和较低级别的实现组件，例如实体、服务和存储库。
其他概念包括强调探索性建模而不是分析、持续的领域沉浸以及使用通用语言进行文档记录。
通过结合建模、语言和基于上下文的技术，DDD 能够创建不仅关注技术需求而且关注领域核心概念的系统。
在这种背景下，六边形架构和干净架构立即浮现在脑海中，它们具有任务分离的共同目标。您可以通过将应用程序划分为松散耦合的组件来将核心业务逻辑与外部问题隔离。
让我们看看定义战略和战术设计的元素以及它们如何影响结果。
策略设计
在 DDD 的背景下，战略设计是软件开发的重要组成部分。它主要包括以下几个方面：
● 概述。战略设计从对问题领域和业务价值的概述开始。在此步骤中，将探索关键概念和流程，并确定关键业务需求和目标。
● 问题空间和解决方案空间。战略设计框架确定了两个主要概念空间：问题空间和解决方案空间。问题空间侧重于探索和分析业务领域，识别实体、聚合、服务以及它们之间的关系。解决方案空间涉及创建一个有效解决问题空间中确定的问题的模型。
● 受限的环境。受限上下文是与特定开发团队的职责范围相对应的领域的有限细分。每个上下文都定义其实体、聚合、服务和规则。管理上下文边界对于隔离和理解域的不同部分至关重要。
● 核心域。核心域是业务的核心，是业务最重要、最有价值的部分。在战略设计中，核心领域至关重要，因为它是开发的重点，并且包含定义软件功能的基本抽象和业务规则。
DDD 背景下的战略设计可以通过考虑业务领域的特征来创建有效的软件开发战略。这有助于开发人员创建满足业务需求、灵活扩展且易于维护的软件。
战术设计
战术设计是软件开发方法的一部分。它负责定义一组工具和方法来创建反映业务领域并确保数据完整性的高效且灵活的架构。
- 首先概述业务领域及其需求。此步骤分析核心流程、实体、聚合以及它们之间的关系。目标是更深入地了解该领域的核心组件。
- 接下来，我们关注应用程序的核心，也称为核心聚合。核心聚合是主要交互元素，包含域的关键逻辑和数据完整性。它定义了核心操作和业务规则。
- 继续讨论战术设计工具包，它为我们提供了一组用于构建有效的应用程序架构的规则和模式。它包括值对象、实体、服务和聚合等概念。该工具包可帮助开发人员创建敏捷架构。
- 使用战术设计工具包的一个例子是创建存储库。存储库负责从特定实体或聚合的存储库中存储和检索数据。它们提供与数据存储库交互的单一接口并封装数据存储细节。
战术设计还区分应用程序服务和领域服务。应用程序服务协调应用程序内不同实体和聚合之间的操作和交互。对于领域服务，它们存储仅与领域模型相关的业务逻辑和操作执行。
总而言之，战术设计有助于创建反映业务领域并保证数据完整性的有效架构。使用战术设计工具可以简化应用程序开发和支持，从而更容易理解和扩展复杂领域。
有界上下文和通用语言：它们在 DDD 中的作用
DDD 中的有界上下文是应用于特定业务领域的一组本地化模型和规则。它有助于在特定上下文中描述和限制系统的不同方面。
有界上下文代表开发发生的边界，并确保该上下文中模型和规则的一致性。因此，它可以有自己的建模语言，甚至特定于业务领域的术语。
它使开发人员能够更好地理解和建模复杂的主题领域，并促进利益相关者的沟通。有限的上下文可以并行存在并通过定义的接口进行交互。
当我们谈论 DDD 时要关注的另一个同样重要的概念是无处不在的语言。
它可以被描述为所有开发团队成员使用和理解的通用语言。
通用语言是在有限的上下文中创建和维护的。它包括反映系统的业务理解和主题的专业术语、短语和规则。这种语言作为熟悉的基础，促进不同团队成员之间的有效沟通。
其主要任务是帮助避免与术语或概念的不同解释和理解相关的误解，并在某种意义上有助于对主题领域进行更深入、更准确的建模。
开启新解决方案的关键：DDD 方法带来了什么，它适合谁？
如果一个项目处理复杂的业务逻辑、不断变化的流程、关系和业务规则，那么它就成为实现领域驱动设计原则的理想选择。通过应用 DDD，开发人员可以有效地驾驭复杂领域并创建准确反映现实世界复杂性的软件解决方案。
DDD 对未来的变化也具有很强的适应性和灵活性。随着企业的发展并面临新的挑战，软件解决方案必须跟上步伐。有限上下文的明确分离和通用语言的使用促进了更新和修改的无缝集成，从而最大限度地减少了重大系统范围更改的需要。其结果是实现平稳过渡、减轻压力水平并节省公司成本。
小型 DDD 团队的力量
领域驱动设计非常适合小型自治团队。“双比萨团队”的概念就体现了这一点。我们的想法是，一个团队应该足够小，只需两个披萨就可以养活。这可以实现专注、协调和生产力。
我们看到“双披萨团队”方法与 DDD 交织在一起，成功应用于 Netflix（这使他们能够快速扩展平台）和 Uber（他们能够灵活地隔离事件并管理需求波动）等行业领导者。
看起来 DDD 是一个专属俱乐部，成员包括 Netflix、Uber 和我们不起眼的 WebLab Technology。我们是很好的伙伴，不是吗？
是的，我们使用 DDD 作为开发复杂业务软件的主要方法之一。我们似乎是少数与之合作的公司之一。
有人在DEV 社区门户上发起了讨论，询问“如何找到遵循领域驱动设计方法的公司？”
要找到 DDD 从业者，请遵循结构良好的对话……或者只是寻找我们的团队！
但有人决定建议你可以找到这样的公司，如果他们在提案中提到他们与 DDD 合作。需求是有的，但报价并不多。
正如您所看到的，小型、有凝聚力的团队在复杂的领域中发挥着至关重要的作用。他们可以快速积累知识并普遍使用其领域的语言。
对于采用 DDD 的公司来说，采用“两块披萨”团队范式可以释放跨领域的生产力和创新。小团队和领域驱动设计的联系是强大的。
特别是，DDD 能够：
● 改进的沟通：无处不在的语言使开发人员和业务专家能够更有效地协作。
● 业务一致性：软件设计直接反映真实的业务流程和目标。
● 灵活性：模块化架构使得可以根据需求的变化轻松修改应用程序。
● 以用户为中心：以领域为中心，可以创建适合用户需求的解决方案。
● 效率：主题专家的密切参与可以产生能够解决实际业务问题的产品。
DDD 和小型组织：可能的挑战
在较小的组织中，DDD 集成可能不像在较大的公司中那样普遍。然而，整合的能力取决于具体的需求和优先事项。如果小型组织具有复杂的主题领域或需要有效管理和建模业务流程，那么 DDD 集成可能会很有帮助。
但是，请为可能出现的障碍做好准备，其中包括：
● 资源有限。较小的组织可能拥有有限的开发人员和时间，这使得实施新方法具有挑战性。
● 主题建模困难。DDD 集成需要对主题领域有深入的了解并对其进行正确的建模。缺乏软件开发经验可能是一个障碍。
● 抵制变革。较小的组织可能更容易抵制变革，特别是在现有流程和软件架构已经建立的情况下。
● 技术限制。过时的技术基础设施不支持完整的 DDD 集成。
事实上，并非所有这些障碍都适用于所有小型组织。每个组织都有可能影响 DDD 集成的独特特征和挑战。
DDD实施：逐步开始
现在，让我们看看有效实施 DDD 的基本步骤，而不被复杂性所困扰。
1 . 从小事做起
建议从小规模开始使用 DDD，尤其是刚接触它或处理大型系统时。选择应用程序中一个小的、不太关键的部分并开始应用 DDD。
2.持续学习
通常，第一次实施可能并不完美。这是一个持续学习的过程。不要因最初的挑战而灰心丧气。了解错误并从中吸取教训。
3.协作
DDD 不仅仅与编码人员有关。它涉及整个团队：开发人员、项目经理、系统分析师、领域专家等。它需要紧密协作，根据业务需求进行知识共享和软件开发。
最后，正如我们之前所说，必须记住 DDD 并不总是适用于所有项目的解决方案。对于简单的应用程序来说，它引入的复杂性可能不是必需的，因此评估其在项目中的需求至关重要。
交叉点：DDD 与敏捷的联系
那么，DDD 与 Agile 的交集如何体现呢？DDD 和敏捷有着相似的原则，为它们的成功集成奠定了基础。
- 与利益相关者积极互动。在 DDD 中，这体现在普遍使用促进有效沟通的语言，而敏捷则侧重于协作来创造价值。
- 灵活性和适应性。两种方法都是适应性强的。敏捷旨在接受和实施变更，而 DDD 模型则不断发展以反映领域理解。
- 迭代开发。敏捷专注于以小规模、渐进的步骤开发软件。在 DDD 中，模型随着发展而不断完善，这让我们回到了敏捷 DDD 的迭代本质。
DDD 和敏捷之间的联系表现为一种互补关系。因此，在敏捷环境中使用 DDD 可以简化沟通，确保更好地符合业务需求，并交付高质量的软件。
我们可以自信地说，严重依赖领域知识的行业在 DDD 专注于学习其特定领域的复杂性方面发现了特殊的价值。最终，以领域为中心的设计的本质在于它能够创建与企业及其客户的需求紧密结合的高质量软件。
对于WebLab Technology来说，DDD 方法是我们与客户建立长期技术合作伙伴关系的理念的一个组成部分。它符合康威定律，该定律指出软件系统反映了构建它们的组织的通信结构。
我们的专业团队创建的架构与客户的领域自然契合，领域专家的深度参与使我们能够创建一个涉及每个人的顺畅的沟通链。也许越多的公司意识到这种方法的必要性，未来就会发现更有价值的 DDD 好处。
毕竟，正如埃里克·埃文斯（Eric Evans）在他的书中所写的那样，“为了有效地沟通，代码必须基于用于编写需求的相同语言 - 开发人员彼此以及与领域专家交谈的相同语言。”
