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

Question

a)这些核心领域和通用子域( GS )在大多数情况下含有相同的域模型的不同部分或是否每个 GS 定义自己的域模型，通常是在核心领域中使用的模型有什么不同？

B)如果是前者，那么我想对于这两个使用相同的模型，因为 GS 的主要目的是“服务”一个核心领域，并 GS 可以“伺候”如果最好的没有必要的理由核心结构域和 GS 之间的转换层(如果每个使用它自己的模式，那么我们也想需要的GS 和核心领域之间的转换层)？

谢谢

Answer 1

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

要回答你的问题，核心域是您公司的独特，让您在你的竞争对手的优势领域 - 你会把大部分精力(开发商/monry)为改进它。一个通用子域 handle 一个主题，仍然是重要的，但有你会发现现有的解决方案的机会(无论是作为一个概念或可重用的代码)，处理任务不够好。

因为它铲球不同的域的通用子域将有一个不同的模型。

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

您可以在Implementing Domain-Driven Design一书中找到详细信息，当然也可以在original book introducing Domain-Driven Design by Eric Evans中找到。

更新:(见注释)

我认为，在使用任何一种子域的核心域中，最重要的方面是不要从抽象的角度考虑这个主题。你可能会同意，在领域驱动设计的最大挑战是要找到很好的例子，通过计划或意外，从Domain-Driven Design book的战略设计部分匹配模式/策略。

现在，从我的理解，需要核心领域之间通用子域一个转换层仅仅从必然出现。在第15章，蒸馏如何发展通用子域Domain-Driven Design四个选项与它们对应的利弊讨论:

一个现成的，现成的解决方案

公布的设计或新型

外包的实现

一个内部实现

我不会重复讨论，因为这将只包括从优秀图书引用。你可能会同意，量身定制和精心设计的内部解决方案，即只用于此项目，并不需要一个转换层。在另一方面，商业或开源现成的，现成的解决方案是可能更需要一种抽象，因为你对产品如何演变难以控制，如果有合适的 释意接口(interface)等。

但是也有一些相关的，但不应该使用子混在一起其他两个方面:

限界上下文 之间

通信

衔接机制

限界上下文需要某种翻译由纯粹的定义。对于每个 界上下文，有一个大的背景一个 模型。 上下文映射记录了有界上下文与翻译映射的关系和交互。 在第14章讨论了有关 BoundedContexts车型的不同方式，Mainting诚信示范企业(反腐败层，开放式主机服务等)。

衔接机制(见Domain-Driven Design的第15章)，在另一方面，类似于通用子域既被引入以减轻核心结构域从不必要的困惑。埃里克·埃文斯(Eric Evans)将内聚机制描述为轻量级框架，但承认在实践中内聚机制和通用子域之间的区别大部分不是纯净的。

我想说，我不得不再次阅读这些章节，因为我不同意这个处理每天的基础上，所以请原谅。另外，我不是在DDD社区内圆，因此我不知道如果这些问题今天不同的评价。他们似乎仍然对我非常有用，我还没有遇到一个更好的工具集，在这一领域，所以我认为他们仍然是有效的。

我理解的冲动，了解这些概念，但真正了解只能通过看具体的例子来实现。有些人在书提及。他们都不是完美的要求。理解和这些复杂的问题，或大或小的评估，随时间变化，这将在我看来DDD的灵魂。