1

埃文的书，第 页。430：

因此，虽然这个例子可能不够复杂，无法将我们推向隔离核心......

a）作者是否暗示除非领域模型非常复杂，否则我们不应该有一个隔离核心？换句话说，除非处理复杂的领域模型，核心领域应该只以文档的形式存在（即领域愿景声明和突出核心），而不应该表现为一个单独的物理实体？

谢谢你

4

4 回答 4

2

对我来说，分离核心是指将域组件组织成完全独立的包，但一起代表同一个核心域。大型核心可能会从这种类型的组织中受益，以澄清领域的组成，或者将支持能力与核心领域概念分开。

于 2013-03-12T00:55:33.423 回答
1

“核心域应该只以文档的形式存在（即域愿景声明和突出核心），”

不，您的核心域不应该仅作为一组文档存在。这违背了领域驱动设计的观点。DDD 的全部要点是您的业务分析工件在您的系统中具有一流的表示。例如，如果您的需求经常讨论 ShippingCargo 的 Route 的概念，并且您没有ShippingCargo和Route的类（代码级工件），那么您做错了。通用语言的重点在于，我们所说的软件所做的事情和它实际所做的事情之间存在紧密的映射。

该技术旨在管理认知负荷，并减少不同利益相关者对系统的术语和推理的阻抗不匹配。

仅将模型保存在文档中是违反DRY的情况。与代码注释和反对它们的各种论点类似，文档变得陈旧并失去价值。这一点我怎么强调都不为过，DDD 的重点是你的代码应该能够在非代码文档的最小支持下显示核心域。

当域对象（实体、值对象等）的数量变得如此之大以至于为了凝聚力和架构简单性而将事物分开时，分离核心特别有用。

此概念的应用示例

观察他们的代码库的演变（你可能需要浏览过去几年来看看事情是如何变化的）。您会注意到，随着这些系统变得越来越大，并与更多的外部系统交互，“核心”模块的想法变得很重要。这就是隔离核心。

于 2013-05-24T19:59:31.540 回答
1

在 pg 上。429 埃文斯说：

当你有一个对系统至关重要的大型有界上下文，但模型的基本部分被大量支持能力所掩盖时，是时候砍掉一个分离的核心了。

分离核心只是一种重构技术，您可以使用它来改进核心模型，使其演变成概念上更具凝聚力的模型。将仅部分服务于 CORE DOMAIN 的元素移动到单独的支持上下文中是隔离核心告诉您要做的。

于 2014-12-21T17:53:22.580 回答
0

整套领域驱动模式和方法只能用于复杂的业务领域。

“复杂”是一个贬义词，当代码模型设计不当或无法提供域驱动应用程序所需的表达能力时，它可以应用于代码模型。此外，初级建模师可能会忽略业务本身的重点，并设计出比业务更复杂的模型（通常是为了寻求灵活性）。

当您使用大型复杂领域以及多年演变的模型时，您通常会累积小型建模债务，类似于众所周知的技术债务。然后，重构为应该只包含最有价值的概念和业务规则（从客户的角度来看）的隔离核心域，可以降低系统的演化成本（即使它本身通常是昂贵的重构）。

但是，当您需要 DDD 时，不仅仅是编写规范文档。您需要 DDD 来理解和处理复杂的业务，通过称为“源代码”的符号表示来表达它们。对我来说，DDD 是一个有价值的业务分析工具，但它的全部意义在于支持对解决复杂业务问题的有价值的应用程序进行编码。

于 2013-03-12T09:18:49.557 回答