除非域模型非常复杂，否则我们不应该使用隔离核心？

Question

Evan的书，pg。 430：

  

因此，虽然这个例子可能不够复杂   把我们带到隔离核心...

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

谢谢

Answer 1

对我来说，隔离核心是指将域组件组织成完全独立的包，但它们共同代表相同的核心域。大型核心可以从这种类型的组织中受益，以阐明域的组成，或将支持功能与核心域概念分开。

Answer 2

“核心域应仅以文档形式存在（即域视觉声明和突出核心），”

没有。您的核心域永远不应该只存在一组文档。这打破了领域驱动设计的重点。 DDD的整体要点是您的业务分析工件在系统中具有First Class表示。例如，如果您的要求定期讨论ShippingCargo路线的概念，并且您没有 ShippingCargo 和路线的类（代码级工件），你做错了。 无所不在的语言的重点在于，我们所说的软件与它实际所做的事情之间存在着紧密的映射。

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

仅在文档中保留模型是违反DRY的情况。与code comments and the various arguments against them类似，文档变得陈旧且失去价值。我不能强调这一点，DDD的全部意义在于您的代码应该能够在非代码文档的最小支持下显示核心域。

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

这个概念的应用实例

• Spock Framework
• Maven
• Geotools

观察其代码库的演变（您可能需要浏览过去几年以了解情况如何变化）。您会注意到，随着这些系统变得更大，并与更多外部系统接口，“核心”模块的想法变得非常重要。这就是隔离核心。

Answer 3

on pg。 429埃文斯说：

  

划分隔离核心的时间是当你有一个对系统至关重要的大型有界环境时，但是模型的基本部分被大量的支持能力所掩盖。

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

Answer 4

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

“复杂”是一种贬义，可以应用于代码模型，如果它没有很好地设计，或者它不提供域驱动的应用程序所需的表达性。此外，初级建模者可能会错过业务本身的重点，并设计出比业务更复杂的模型（通常是为了寻求灵活性）。

当您处理大型复杂域和多年来发展的模型时，您经常会累积小型建模债务，类似于众所周知的技术债务。然后，重构一个应该只包含最有价值的概念和业务规则的隔离核心域（从客户的角度来看），使系统的发展变得更便宜（即使它本身通常是一个昂贵的重构）。

但是，当您需要DDD时，这不仅仅是编写规范文档。您需要DDD来理解和处理复杂的业务，通过称为“源代码”的符号表示来表达它们。就我而言，DDD是一种有价值的业务分析工具，但其重点是能够编写有价值的应用程序，以解决复杂的业务问题。