a）核心域和通用子域（ GS >在大多数情况下包含相同域模型的不同部分< / em>或每个 GS 定义其自己的域模型，这通常与核心域中使用的模型不同 EM>
b）如果是前者，那么我认为使用相同模型的原因是因为 GS 的主要目的是“服务”如果核心域和
感谢
答案 0 :(得分：12)
核心域，支持子域和通用子域围绕DDD中 Bounded Context 的概念发展。
要回答您的问题，核心域是使您的业务与众不同并让您比竞争对手更具优势的域 - 您将尽最大努力（开发人员/ monry）进行改进。 通用子域处理一个仍然很重要的主题，但您可能会找到一个现有的解决方案（作为概念或可重用代码）来处理足够好的任务。
通用子域将具有不同的模型，因为它处理不同的域。
通用子域可以描述从日期/时间（区域）处理看到的任何内容（2，第15章），持久性，用户界面工具包直到邮件服务器或完整的库存管理系统（1，第2章）。另一方面，库存管理逻辑是库存管理系统供应商的核心域。
您可以在书籍Implementing Domain-Driven Design中找到更深入的信息，当然也可以在original book introducing Domain-Driven Design by Eric Evans中找到。
更新（见评论）
在我看来，使用任何类型的子域的核心域中最重要的方面不是在抽象层面上过度讨论这个主题。您可能会同意域驱动设计中的最大挑战是找到好的示例，按计划或意外地匹配战略设计部分中的模式/策略Domain-Driven Design book。
现在，根据我的理解，需要在核心域和通用子域之间建立转换层。在第15章中，讨论了Domain-Driven Design关于如何开发通用子域的四个选项的 Distillation 及其相应的优缺点：
我不会重复讨论，因为这只会引用优秀的书。您可能会同意，仅用于此项目的定制且精心设计的内部解决方案不需要转换层。另一方面，商业或开源的现成解决方案更可能需要抽象，因为如果它具有适当的意图 - 显示界面等等。
还有两个相关的方面，但不应与子域名混淆：
有界上下文需要通过纯粹的定义进行某种翻译。对于每个有界上下文，上下文中都有模型。 上下文地图会记录有界上下文与翻译地图的关系和互动。关于 BoundedContexts 模型的不同方式将在第14章讨论，维护模型完整性（反腐败层，开放主机服务等）。
另一方面，衔接机制（参见Domain-Driven Design的第15章）类似于通用子域，因为两者都是为了缓解核心域来自不必要的混乱。 Eric Evans将 Cohesive Mechanisms 描述为轻量级框架，但承认在实践中区分 Cohesive Mechanisms 和 Generic Subdomains 绝大多数都不纯洁。
我想说我必须再次阅读这些章节，因为我每天都没有处理这个问题所以请原谅。此外，我不是DDD社区的核心圈子，因此我不知道今天是否对这些问题进行了不同的评估。它们对我来说似乎仍然非常有用，我在这方面没有遇到过更好的工具，所以我认为它们仍然有效。
我理解理解这些概念的冲动，但只有通过查看具体的例子才能真正理解。书中提到了一些。他们都没有被声称完美。对这些复杂问题的理解和评估，无论大小，都会随着时间的推移而发生变化，这也是我认为DDD的灵魂。