5

a)在大多数情况下，核心域和通用子域( GS ) 是否包含同一域模型的不同部分，或者每个 GS是否定义了自己的域模型，这通常与核心域中使用的模型不同？

b）如果是前者，那么我认为两者使用相同模型的原因是因为GS的主要目的是“服务”一个Core Domain，如果不需要在Core Domain和GS（如果每个都使用自己的模型，那么我们还需要GS和Core Domain之间的转换层）？

谢谢

4

1 回答 1

17

核心域、支持子域和通用子域围绕DDD中的限界上下文的概念发展。

为了回答您的问题，核心域是使您的业务独一无二并为您提供优于竞争对手的优势的域 - 您将投入大部分精力（开发人员/monry）来改进它。通用子域处理的主题仍然很重要，但您有机会找到处理任务足够好的现有解决方案（作为概念或可重用代码）。

通用子域将具有不同的模型，因为它处理不同的域。

通用子域可以描述从日期/时间（区域）处理见（2，第 15 章）、持久性、用户界面工具包到邮件服务器或完整的库存管理系统（1，第 2 章）的任何内容。另一方面，库存管理逻辑是库存管理系统供应商的核心域。

您可以在《实现领域驱动设计》一书中找到深入的信息，当然也可以在Eric Evans 的《领域驱动设计介绍》原书中找到。

更新：（见评论）

在我看来，使用任何类型的子域的核心域中最重要的方面是不要在抽象层面上过度思考这个主题。您可能会同意，领域驱动设计中最大的挑战是找到好的示例，无论是计划中还是意外， 都与领域驱动设计一书的战略设计部分中的模式/策略相匹配。

Now, from my understanding, the need for a translation layer between Core Domain and Generic Subdomains arises simply from necessity. In Chapter 15, Distillation of Domain-Driven Design four options on how to develop Generic Subdomains are discussed with their corresponding pros and cons:

  1. An Off-the-Shelf Solution
  2. A Published Design or Model
  3. An Outsourced Implementation
  4. An In-House Implementation

我不会重复讨论，因为这只会包括引用优秀书籍的内容。您可能会同意，仅用于该项目的定制和精心设计的内部解决方案不需要翻译层。另一方面，商业或开源的现成解决方案更有可能需要抽象，因为您几乎无法控制产品的发展方式，如果它具有适当的意图显示接口等等。

还有另外两个相关但不应与子域混淆的方面：

  • 限界上下文之间的通信
  • 凝聚机制

有界上下文需要通过纯粹的定义进行某种翻译。对于每个有界上下文，上下文中都有一个模型。上下文映射记录了有界上下文 与翻译映射的关系和交互。在第 14 章，维护模型完整性（反腐败层，开放主机服务等）中讨论了关联模型的不同方式。

另一方面，内聚机制（参见域驱动设计的第 15 章）与通用子域相似，因为它们的引入都是为了使核心域免于不必要的混乱。Eric Evans 将Cohesive Mechanisms描述为一个轻量级框架，但承认在实践中Cohesive Mechanisms和Generic Subdomains之间的区别大多不是纯粹的。

我想说我不得不再次阅读这些部分，因为我不是每天都处理这个问题，所以请原谅。此外，我不在 DDD 社区的核心圈子中，因此我不知道今天是否对这些问题进行了不同的评估。它们对我来说似乎仍然非常有用，而且我在这方面还没有遇到更好的工具集，所以我认为它们仍然有效。

我理解理解这些概念的冲动，但只有通过查看具体示例才能真正理解。书中提到了一些。他们都没有声称是完美的。对这些复杂问题的理解和评估，无论大小，都会随着时间的推移而发生变化，这也是我认为 DDD 的灵魂所在。

于 2013-06-07T14:44:56.407 回答