有人可以用简单的英语解释域驱动设计(DDD)吗?

lee*_*n3o 258 domain-driven-design

我一直看到DDD(领域驱动设计)在文章中被大量使用 - 我已经阅读了有关DDD的维基百科条目,但仍然无法弄清楚它实际上是什么以及如何在创建我的网站时实施它?

Rob*_*ght 547

首先,如果你不知道你需要它,那么你可能不需要它.如果您没有意识到DDD解决的问题,那么您可能没有遇到这些问题.即使DDD倡导者也经常指出DDD仅适用于大型(> 6个月)项目.

假设你现在还在阅读,我对DDD的看法是这样的:

DDD旨在使您的软件成为真实世界系统或流程的模型.在使用DDD时,您需要与可以解释现实世界系统如何工作的领域专家密切合作.例如,如果您正在开发一个处理在赛马上下注的系统,那么您的域名专家可能是一位经验丰富的博彩公司.

在您自己和领域专家之间,您构建了一种无处不在的语言(UL),它基本上是对系统的概念性描述.我们的想法是,您应该能够以域专家可以读取它并验证它是否正确的方式记下系统的功能.在我们的投注示例中,无处不在的语言将包括诸如"种族","下注","赔率"等词语的定义.

UL描述的概念将构成面向对象设计的基础.DDD为您的对象应如何交互提供了一些明确的指导,并帮助您将对象划分为以下类别:

  • 值对象,表示可能包含子部分的值(例如,日期可能包含日,月和年)
  • 实体,是具有身份的对象.例如,每个Customer对象都有自己的标识,因此我们知道具有相同名称的两个客户不是同一个客户
  • 聚合根是拥有其他对象的对象.这是一个复杂的概念,其工作原理是,除非拥有所有者,否则有些对象没有意义.例如,如果没有'Order'属于'Order Line'对象没有意义,所以我们说Order是聚合根,Order Line对象只能通过Order对象中的方法来操作

DDD还推荐了几种模式:

  • 存储库,一种持久性模式(通常存储到数据库或从数据库加载数据)
  • 工厂,对象创建的模式
  • 服务,一种用于创建操作主域对象的对象的模式,而不是域本身的一部分

现在,在这一点上,我必须说,如果您之前没有听说过任何这些事情,那么您不应该尝试在任何有截止日期的项目中使用DDD.在尝试DDD之前,您应该熟悉设计模式企业设计模式.了解这些使DDD更容易掌握.而且,如上所述,InfoQ提供了免费的DDD介绍(在这里您也可以找到有关DD​​D的讨论).

  • 哇...多么好的回复!非常感谢,并且我已经阅读了一英里的最佳解释.谢谢..明天我会下载那本书. (32认同)
  • 顺便说一句,我们不会对我们做的每个项目或模型进行域分析.难道我们还没有结束与客户和中小企业的BA对话以了解项目领域和范围吗?我仍然不明白DDD中的其他任何软件开发项目都非常出色? (6认同)
  • 说实话,这听起来像是开发人员与建筑师合作一个多月的每个项目.(嗯,根据我的经验,至少.)哪种实现让我更加欣赏你的答案.:) (5认同)
  • 我不同意DDD"仅适用于大型项目"的说法.DDD不是你必须完全或根本不做.你可以从DDD做一些练习.例如,你可以只做"价值对象"和"无处不在的语言",而不是在一个小项目中进行聚合. (3认同)
  • "聚合根是拥有其他对象的对象.这是一个复杂的概念,并且基于某些对象没有意义,除非他们拥有所有者."我认为这可能是误解,你提到的想法是"整体价值",而聚合更关注交易边界,其中所有商业不变规则都需要在这里强制执行. (2认同)

Mat*_*lls 42

以StackOverflow为例.您不必开始设计某些Web表单,而是首先集中精力对问题域中的实体进行面向对象的建模,例如用户,问题,答案,投票,评论等.因为设计是由问题的细节驱动的域称为域驱动设计.

您可以在Eric Evans的书中阅读更多内容.

  • 埃里克埃文斯的书有一个简短的版本[免费提供](http://www.infoq.com/minibooks/domain-driven-design-quickly). (5认同)
  • 我也是,这只是一个面向对象的设计,即使在这个概念出现之前,每个人都会使用它.我在这里看不到任何新发明. (5认同)
  • 但老实说,谁会从设计表格开始呢?任何可敬的学术课程都将根据业务需求进行分析,设计和建模应用.我只是没有得到这种技术的新功能. (3认同)
  • @RonenFestinger请不要仅凭此答案来判断DDD。埃里克·埃文斯(Eric Evans)的书中有很多见解。例如有界上下文。绑定上下文范式是我们今天构建的微服务的支柱之一。阅读本书还可以帮助您了解微服务。 (2认同)