Domain driven design 核心域和通用子域是否包含同一域模型的不同部分？

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

b） 如果是前者，那么我假设两者使用相同模型的原因是因为GS的主要目的是“服务”核心域，如果核心域和GS之间不需要翻译层，那么GS可以“服务”得最好（如果每个都使用自己的模型，那么我们还需要在GS和核心域之间建立一个转换层）

---

感谢

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

为了回答您的问题，核心领域是使您的业务独一无二并使您比竞争对手更具优势的领域-您将付出最大努力（开发者/monry）一个通用子域处理一个仍然很重要的主题，但您有可能找到一个现有的解决方案（作为概念或可重用代码）来足够好地处理任务

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

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

你可以在书中找到深入的信息，当然也可以在网站上找到

更新：（见评论）

在我看来，核心领域使用任何类型的子域最重要的方面是不要在抽象的层面上过度思考这个主题。你可能会同意，领域驱动设计的最大挑战是找到好的例子，通过计划或偶然的方式，与Strat的模式/策略相匹配本课程的egic设计部分

现在，根据我的理解，核心域和通用子域之间需要一个转换层，这仅仅是出于必要性。在第15章中，对如何开发通用子域的四个选项进行了提炼，并讨论了它们相应的优缺点：

现成的解决方案

已出版的设计或模型

外包实施

内部实施

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

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

• 有界上下文之间的通信
• 内聚机制

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

内聚机制（见第15章）另一方面，与通用子域类似，因为这两个子域的引入都是为了将核心域从不必要的混乱中释放出来。Eric Evans将内聚机制描述为一个轻量级框架，但承认在实践中，内聚机制和之间的区别g> 一般子域大多不是纯的

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

---

我理解理解这些概念的迫切性，但真正的理解只能通过看具体的例子来实现。书中提到了一些例子。没有一个被认为是完美的。对这些复杂问题的理解和评估，无论大小，随着时间的推移而变化，在我看来，这就是DDD的灵魂。

我正在阅读“引入DDD”，因此我已经知道你告诉我的一切，除了“通用子域将具有不同的模型，因为它处理不同的域。”但正如我在问题b中已经指出的那样，如果GS和核心域具有不同的模型（而不是都包含同一域模型的不同部分），那么这不意味着核心域需要有一个翻译层才能与GS进行通信吗？我对翻译层主题做了更多的解释，顺便提一下，这是一个非常好的问题，花了相当长的时间思考和阅读：-）。“…设计良好的内部解决方案，仅用于本项目，