什么是领域驱动设计？

Question

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

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

Answer 1

编辑:

由于这似乎是谷歌的最佳结果,我的答案不是,请参考这个更好的答案:

/sf/answers/85574191/

老答案(不是那么完整:))

为了创建好的软件,您必须知道该软件的用途.除非您对银行业务的理解有充分的了解,否则您无法创建银行业务软件系统,必须了解银行业务领域.

来自:Eric Evans的领域驱动设计.

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

注册下载该书的摘要,或直接下载摘要.

Answer 2

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

域驱动设计的重点是理解问题域,以便创建问题域的抽象模型,然后可以在特定的一组技术中实现.领域驱动设计的方法提供了这种模式的发展和技术的发展如何可能会导致在满足使用它同时还在问题领域面对变化健壮的人的需求的系统指导.

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

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

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

领域驱动设计:善与挑战提供了以下评论的简要概述:

DDD有助于发现顶级架构,并告知软件需要复制的域的机制和动态.具体而言,这意味着完善的DDD分析可以最大限度地减少领域专家和软件架构师之间的误解,并减少随后的昂贵变更请求数量.通过在较小的上下文中分割域复杂性,DDD避免迫使项目架构师设计一个膨胀的对象模型,这是在计算实现细节时浪费了大量时间 - 部分原因是要处理的实体数量经常超出会议室白板的大小.

另请参阅本文"服务架构的域驱动设计",它提供了一个简短的示例.本文提供了域驱动设计的以下缩略图描述.

Domain Driven Design主张基于与我们的用例相关的业务现实进行建模.由于它现在变得越来越老,炒作水平越来越低,我们中的许多人都忘记了DDD方法确实有助于理解手头的问题并设计软件以达到对解决方案的共同理解.在构建应用程序时,DDD将问题称为域和子域.它描述的问题,独立的步骤/地区为界背景,强调了一个共同的语言来谈论这些问题,并增加了许多技术概念,比如实体,值对象和聚合根规则,以支持实施.

Martin Fowler撰写了许多文章,其中提到了Domain Driven Design作为一种方法.例如,本文BoundedContext概述了Domain Driven Development中的有界上下文概念.

在那些年轻的时候,我们被建议建立一个统一的整个业务模型,但DDD认识到我们已经了解到"大型系统的域模型的完全统一将不可行或具有成本效益" 1.因此,DDD将一个大型系统划分为有界上下文,每个上下文都可以有一个统一的模型 - 本质上是一种构造MultipleCanonicalModels的方法.

Answer 3

您只能通过首先理解以下内容来理解域驱动设计:

什么是域名？

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

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

什么是模特？

"对手头的问题有用的近似." - 格里苏斯曼

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

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

什么是域名模型？

域的模型.

什么是域驱动设计(DDD)？

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

从这里剔除

Answer 4

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

希望有所帮助.

Answer 5

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

当系统分析师、产品负责人、开发团队和当然代码——实体/类、变量、函数、用户界面进程使用相同的语言进行通信时，类似的方式，称为领域驱动设计

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

有许多方法可以使用 DDD 对系统建模

• 事件溯源（使用事件作为单一事实来源）
• 关系数据库
• 图数据库
• 使用函数式语言

域对象：

用非常天真的话说，一个对象

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

Answer 6

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

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

• 当您与没有技术概念的非技术人员打交道时，这种冲突可能会给我们的项目带来一些巨大的问题。

因此，DDD 处理第一个问题是将主项目视为一个域，并将该项目的每个部分拆分为小块，我们以有界上下文而闻名，并且每个小块都不会对其他部分产生任何影响。第二个问题已经用一种无处不在的语言解决了

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