a)核心域和通用子域（GS）在大多数情况下包含相同域模型的不同部分 或者 each GS 是否定义了自己的自己的域模型，这通常与Core Domain中使用的模型不同em>？
b) 如果是前者，那么我假设两者都使用 相同的模型 的原因是因为 GS 的主要目的是“服务”一个 核心域，如果 核心域 和 之间不需要翻译层，GS 可以“服务”得最好>GS（如果每个都使用自己的模型，那么我们还需要在 GS 和 之间有一个翻译层 >核心领域）？
谢谢
【问题讨论】：
核心域、支持子域和通用子域围绕 DDD 中的有界上下文的概念发展。
为了回答您的问题，核心域是使您的业务与众不同并为您提供优于竞争对手的优势的域 - 您将投入大部分精力（开发人员/monry）来改进它。 通用子域处理的主题仍然很重要，但您有机会找到处理任务足够好的现有解决方案（作为概念或可重用代码）。
通用子域将具有不同的模型，因为它处理不同的域。
通用子域可以描述从日期/时间（区域）处理见（2，第 15 章）、持久性、用户界面工具包到邮件服务器或完整的任何内容库存管理系统（1，第 2 章）。另一方面，库存管理逻辑是库存管理系统供应商的Core Domain。
您可以在本书Implementing Domain-Driven Design 中找到深入的信息，当然也可以在original book introducing Domain-Driven Design by Eric Evans 中找到。
更新：（见评论）
在我看来，核心域中使用任何类型的子域最重要的方面是不要在抽象层面上过度思考这个主题。您可能会同意，领域驱动设计 中的最大挑战是找到符合战略设计 部分中的模式/策略的好的示例，无论是计划中还是偶然Domain-Driven Design book.
现在，据我了解，Core Domain 和 Generic Subdomains 之间的翻译层的需求仅仅是出于必要性。在第 15 章中，Distillation of Domain-Driven Design 讨论了如何开发 通用子域 的四个选项及其相应的优缺点：
我不会重复讨论，因为这只会包括引用优秀书籍的内容。您可能会同意，仅用于该项目的定制和精心设计的内部解决方案不需要翻译层。另一方面，商业或开源的现成解决方案更有可能需要抽象，因为如果产品具有适当的Intention-Revealing Interface，您几乎无法控制产品的发展方式> 等等。
还有两个相关的方面，但不应与子域混淆：
有界上下文需要通过纯粹的定义进行某种翻译。对于每个Bounded Context，都有一个Model in Context。 Context Map 记录了Bounded Contexts 与Translation Map 的关系和交互。在第 14 章，维护模型完整性（Anti-Corruption Layer，Open-Host）中讨论了关联模型的不同方式 BoundedContexts服务和其他）。
另一方面，内聚机制（参见Domain-Driven Design 的第 15 章）类似于 通用子域，因为它们的引入都是为了减轻 核心域 避免不必要的混乱。 Eric Evans 将 Cohesive Mechanisms 描述为 轻量级框架，但承认在实践中 Cohesive Mechanisms 和 Generic Subdomains 之间的区别大多不纯。
我想说我不得不再次阅读这些部分，因为我不是每天都处理这个问题，所以请原谅。此外，我不在 DDD 社区的核心圈子中，因此我不知道今天是否对这些问题进行了不同的评估。它们对我来说似乎仍然非常有用，而且我还没有在这方面遇到过更好的工具集，所以我认为它们仍然有效。
我理解理解这些概念的冲动，但只有通过查看具体示例才能真正理解。书中提到了一些。他们都没有声称是完美的。对这些复杂问题的理解和评估，无论大小，都会随着时间的推移而变化，这也是我认为 DDD 的灵魂。
【讨论】：