什么是领域驱动设计？

Question

有人可以解释（用简洁的术语）究竟是什么是域驱动设计？我看到这个词很多但是真的不明白它是什么或它看起来像什么。它与非域驱动设计有何不同？

另外，有人可以解释域对象是什么吗？域名与普通对象有何不同？

Answer 1

编辑：

由于这似乎是Google上的最佳结果，而我的答案不是，请参考这个更好的答案：

https://stackoverflow.com/a/1222488/1240557

OLD ANSWER（不太完整:)）

  

为了创建好的软件，你必须知道那个软件是什么   就是这样。除非您，否则无法创建银行软件系统   我必须清楚地了解银行业务的全部内容   了解银行业的领域。

来自：Eric Evans的领域驱动设计。

这本书在描述DDD方面做得很好。

Register to download a summary of the book或download the summary directly。

Answer 2

域驱动设计是开发复杂系统的方法和流程处方，其重点是将问题域中的活动，任务，事件和数据映射到解决方案域的技术工件中。

域驱动设计的重点是理解问题域，以便创建问题域的抽象模型，然后可以在特定的一组技术中实现。领域驱动设计作为一种方法提供了指导，指导该模型开发和技术开发如何能够使系统满足使用它的人们的需求，同时在面对问题领域的变化时也是健壮的。

域驱动设计的流程方面涉及领域专家，了解问题领域的人员以及了解解决方案领域的设计/架构专家之间的协作。我们的想法是拥有一个共享语言的共享模型，以便来自这两个不同领域的人们以两种不同的视角讨论解决方案，他们实际上是在讨论共享知识库和共享概念。

需要特定系统的人与设计和实施系统的人之间缺乏共享问题领域理解似乎是成功项目的核心障碍。领域驱动设计是一种解决这一障碍的方法。

它不仅仅是一个对象模型。重点是共享通信和改进协作，以便发现问题域中的实际需求，并创建适当的解决方案以满足这些需求。

Domain-Driven Design: The Good and The Challenging提供了此评论的简要概述：

  

DDD有助于发现顶级架构并了解相关信息   软件需要的域的机制和动态   复制。具体而言，这意味着做得好的DDD分析   最大限度地减少领域专家和软件之间的误解   架构师，它减少了随后的昂贵请求数量   为了改变。通过在较小的上下文中分割域复杂性，   DDD避免强制项目架构师设计膨胀对象   模特，这是在锻炼中耗费大量时间的地方   实现细节 - 部分原因是实体数量   处理经常超出会议室白板的规模。

另请参阅本文Domain Driven Design for Services Architecture，其中提供了一个简短示例。本文提供了域驱动设计的以下缩略图描述。

  

领域驱动设计倡导基于现实的建模   与我们的用例相关的业务。因为它现在变老了   炒作水平下降，我们很多人忘记了真正的DDD方法   有助于理解手头的问题并设计软件   对解决方案的共同理解。在构建应用程序时   DDD将域名和子域名作为问题进行讨论。它描述了   独立的步骤/问题领域作为有限的背景，强调a   共同语言谈论这些问题，并增加了许多技术   概念，如实体，值对象和聚合根规则   支持实施。

Martin Fowler撰写了许多文章，其中提到了Domain Driven Design作为一种方法论。例如，本文BoundedContext概述了域驱动开发中的有界上下文概念。

  

在那些年轻的时候，我们被建议建立一个统一的模型   整个企业，但DDD认识到我们已经学会了“总计   大型系统的域模型的统一将不会   可行的或具有成本效益的“1。因此，DDD分为一大部分   系统进入有界上下文，每个上下文都可以有一个统一的模型 -   本质上是一种构造MultipleCanonicalModels的方法。

Answer 3

您 CAN ONLY 了解域驱动设计，首先要了解以下内容：

  

什么是域名？

     

构建系统的字段。机场管理，保险销售，咖啡店，轨道飞行，你的名字。

     

应用程序跨越多个不同的域并不罕见。例如，在线零售系统可能在运输领域工作（根据项目和目的地选择适当的交付方式），定价（包括促销和用户特定的定价，比如地点）和建议（计算相关）产品按购买历史记录）。

     

什么是型号？

     

“对手头问题的有用近似。” - 格里·苏斯曼

     

员工类不是真正的员工。它模拟真正的员工。我们知道该模型并未捕获有关真实员工的所有信息，而这并非如此。它只是为了捕捉我们对当前背景感兴趣的东西。

     

不同的域可能会以不同的方式对同一事物建模感兴趣。例如，薪资部门和人力资源部门可能以不同的方式对员工进行建模。

     

什么是域名模型？

     

域名模型。

     

什么是域驱动设计（DDD）？

     

这是一种深入评估域模型并将其连接到实现的开发方法。 DDD是由Eric Evans创造并最初开发的。

从here

中挑选出来

Answer 4

以下是您可以在Domain Driven Design查看的另一篇好文章。如果你的申请比大学任务严重。基本前提是构建实体周围的所有内容，并拥有强大的域模型。区分提供基础设施相关事物的服务（如发送电子邮件，持久化数据）和实际执行核心业务需求的服务。

希望有所帮助。

Answer 5

DDD（领域驱动设计）是一个有用的概念，用于分析项目需求并处理这些需求的复杂性。在此之前，人们在考虑类和表之间的关系来分析这些需求之前，实际上他们的设计是基于在数据库表关系上，它虽然不老，但存在一些问题：

• 在具有复杂需求的大型项目中，它虽然是小型项目的一种很好的设计方式，但却没有用。

• 当您与他们没有的技术人员打交道时，这种冲突可能会在我们的项目中引起一些巨大的问题。

因此，DDD处理第一个问题是将主项目视为一个域，并将该项目的每个部分分成一些我们在绑定上下文中比较有名的小块，而每个小块对其他块都没有任何影响。 第二个问题已通过一种普遍存在的语言解决了，这是技术团队成员和产品所有者之间的通用语言，他们不是技术人员，但对他们的要求有足够的了解

通常，域的简单定义是为所有者和其他团队赚钱的主要项目。

Answer 6

与TDD和BDD一样，您/团队最关注系统的测试和行为，而不是代码实现。

系统分析师，产品所有者，开发团队以及当然的代码-实体/类，变量，函数，用户界面流程使用相同的语言（称为域驱动设计）进行通信的类似方式

DDD是一个思考过程。在对软件设计进行建模时，您需要将业务领域/流程放在关注的中心，而不是数据结构，数据流，技术，内部和外部依赖性。

有很多使用DDD进行系统项建模的方法

• 事件源（使用事件作为单一事实来源）
• 关系数据库
• 图形数据库
• 使用功能语言

域对象：

天真的话，一个物体

• 具有基于业务流程/流程的名称
• 可以完全控制其内部状态，即公开用于操作状态的方法。
• 在使用时始终遵守所有业务不变式/业务规则。
• 遵循单一责任原则

Answer 7

我相信以下pdf文件将为您提供更大的了解。 Domain Driven Design by Eric Evans

注意：考虑您可以从事的项目，运用您了解的小知识并查看最佳实践。它还将帮助您增强对微服务架构设计方法的能力。

Answer 8

我不想重复别人的回答，所以，总之，我解释一些常见的误解

• 实用资源：PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett
• 这是用于复杂业务系统的方法。与业务专家交流时，它消除了所有技术问题
• 它在整个开发团队中提供了对业务（简化和精炼模型）的广泛了解。
• 通过使用普遍存在的语言（整个开发团队，业务专家，业务分析师等可以理解的语言）使业务模型与代码模型保持同步，该语言用于内部通信开发人员团队或其他团队的开发人员
• 与项目管理无关。虽然它可以完美地用于敏捷等项目管理方法。

• 您应该避免在整个项目中都使用它

  DDD强调需要将最大的精力集中在核心子域上。核心子域是 产品区域是成功与失败之间的区别。它的 产品的独特卖点，即产品被制造而非购买的原因。

  基本上，这是因为这需要太多时间和精力。因此，建议将整个域分解为子域，并将其应用于具有较高业务价值的领域。 （例如，不在电子邮件等通用子域中，...）

• 这不是面向对象的编程。主要是解决问题的方法，并且（sometimes）不需要在其中使用OO模式（例如“四人帮”）您的域模型。仅仅是因为业务专家无法理解它（他们对Factory，Decorator等了解不多）。在DDD中甚至有一些模式（例如“事务脚本”，“表模块”）并非100％与OO概念保持一致。