Edv*_*usj 4 domain-driven-design
a)核心域和通用子域(GS)在大多数情况下是否包含相同域模型的不同部分,或者每个 GS是否定义了自己的域模型,这通常与核心域中使用的模型不同？
b)如果是前者,那么我认为使用相同模型的原因是因为GS的主要目的是"服务" 核心域,如果不需要在两者之间存在转换层,GS可以"服务"最佳.核心域和GS(如果每个都使用自己的模型,那么我们还需要GS和核心域之间的转换层)？
谢谢
Jen*_*ahn 13
核心域,支持子域和通用子域围绕DDD 中的有界上下文的概念发展.
为了回答您的问题,核心域是使您的业务与众不同并使您比竞争对手更具优势的域 - 您将尽最大努力(开发人员/ monry)进行改进.一个通用子域处理一个主题,仍然是重要的,但有你会发现现有的解决方案的机会(无论是作为一个概念或可重用的代码),处理任务不够好.
通用子域将具有不同的模型,因为它处理不同的域.
一个通用子域可以描述从日期/时间(区)处理请参见(任何2篇.15),持久性,用户界面工具包到一个邮件服务器或一个完整的库存管理系统(1,通道2).另一方面,库存管理逻辑是库存管理系统供应商的核心域.
您可以在" 实施领域驱动设计 "一书中找到深入的信息,当然也可以在Eric Evans介绍域驱动设计的原始书中找到.
更新:(见评论)
在我看来,使用任何类型的子域的核心域中最重要的方面不是在抽象层面上过度思考这个主题.您可能会同意,域驱动设计中的最大挑战是找到好的示例,通过计划或意外地匹配域驱动设计书的战略设计部分中的模式/策略 .
现在,根据我的理解,核心域和通用子域之间的转换层的需求仅仅源于必要性.在第15章,域驱动设计的蒸馏中,讨论了如何开发通用子域的四个选项及其相应的优缺点:
我不会重复讨论,因为这只会引用优秀的书.您可能会同意,仅用于此项目的定制且精心设计的内部解决方案不需要转换层.另一方面,商业或开源的现成解决方案更可能需要抽象,因为如果产品具有适当的Intention-Revealing Interface等,您几乎无法控制产品的演变.
还有两个相关的方面,但不应与子域混淆:
有界上下文需要通过纯粹的定义进行某种翻译.对于每个有界上下文,在上下文中都有一个模型.一个语境映射文件的关系和相互作用的限界上下文 与翻译地图.关于车型的不同方式BoundedContexts在第14章中讨论Mainting诚信示范企业(反腐败层,开放式主机服务等).
另一方面,内聚机制(参见域驱动设计的第15章)类似于通用子域,因为两者都是为了减轻核心域不必要的混乱而引入的.Eric Evans将Cohesive Mechanisms描述为一个轻量级框架,但承认在实践中,Cohesive Mechanisms和Generic Subdomains之间的区别大多不是纯粹的.
我想说我必须再次阅读这些章节,因为我每天都不处理这个问题所以请原谅.此外,我不在DDD社区的核心圈子中,因此我不知道今天是否对这些问题进行了不同的评估.它们对我来说似乎仍然非常有用,我在这方面没有遇到过更好的工具,所以我认为它们仍然有效.
我理解理解这些概念的冲动,但只有通过查看具体的例子才能真正理解.书中提到了一些.他们都没有被声称完美.对这些复杂问题的理解和评估,无论大小,都会随着时间的推移而发生变化,这也是我认为DDD的灵魂.