“抽象核心”和“可插拔组件框架”概念有什么区别？

Question

我正在阅读由Evans编写的领域驱动设计()，其中有两个子章节--抽象核心和可插拔组件框架--在我看来，这是一个相同的概念。我相信有一个微妙的区别，但我错过了。

抽象核

识别模型中最基本的概念，并将它们分解为不同的类、抽象类或接口。设计这个抽象模型，使其能够表达重要组件之间的大部分交互。将这个抽象的整体模型放在它自己的模块中，而专门的、详细的实现类则留在由子域定义的自己的模块中。

可插入组件框架

提取接口和交互的抽象核心，并创建允许这些接口的不同实现被自由替换的框架。同样，允许任何应用程序使用这些组件，只要它严格地通过抽象核心的接口操作。

在这两种情况下，作者都提到提取抽象核心，在这两种情况下，按照我的观点，本Core将描述组件是如何组合在一起的。此外，在可插拔组件框架章节，这本书有一个例子，软件来自SEMATECH (SEMATECH CIM框架)，这正是抽象核心说它应该做什么。

一个能使差别更加明显的例子将有助于更好地理解这些概念。

Answer 1

因此，第一句话描述了作者所说的“抽象核心”的含义。在建模核心域时，您将拥有对客户端可见的“表面级”元素(应用程序逻辑、用例)，并充当核心“内部”的API，以便在开发/重构时操作实现细节。这些“表面级”类/函数/数据类型代表了核心模型的基本功能，理想情况下，这些类/函数/数据类型的设计具有足够的表现力，因此客户端的逻辑可以用这些元素来表示；这就是抽象核心。

在书中，当一个概念在所有的大写中呈现时，它通常意味着它是对文本中其他地方定义的概念的引用。

现在，具有抽象(例如抽象核心)并不意味着它是可扩展的，或者从客户端的角度来看，幕后实现是部分或完全可交换的，或者通过组合根(如果应用程序使用DI)。在“完全可交换”的情况下，抽象核心可能执行一些有用的高级功能。为了支持这种可扩展性，抽象核心需要专门为它设计(这不一定是一件容易做好的事情，也不是没有成本的事情，所以这不应该被看作是一种规则，而是需要考虑的选项之一)。您需要规划和定义可以插入外部代码的扩展点(例如，通过实现接口或基类，并通过一些API注册自己)。因此，在第二个引语中，重点是“并创建一个允许这些接口的不同实现被自由替换的框架”。

对于最后一点，“允许任何应用程序使用这些组件”，设想一个可重用组件库(不是通用组件，而是域的一个特定方面)，客户端(或应用程序组合者)可以自由选择并插入此框架，以配置他们所需的功能，或者一个场景，其中每个应用程序团队都可以使用抽象核心提供的服务，但可以开发自己的组件以获取详细信息。客户端逻辑本身将通过框架/抽象核心；这需要一些编程规程、团队成熟度，而且它给客户端带来了一些负担，因为他们需要知道(其中一些)这些组件，以便选择适合他们需求的组件；如果您可以提供合理的默认值，则可以减轻这种负担。

请注意，本章的开头是：

机会出现在一个非常成熟的模式中，这个模式是深层次和精馏的。可插拔组件框架通常只在少数几个应用程序已经在同一域中实现之后才起作用。

因此，我们的想法是，这可能是由于对几个应用程序的领域概念的精细理解而产生的，每个应用程序都可能有自己的相同领域的模型(表示)，并且有重要的概念重叠。此场景中的抽象核心捕捉到了这种重叠(即，它对所有这些应用程序都具有重要价值)，并且通过允许可插拔的行为来支持特定于应用程序的需求。这本书还指出，在这个方向上的努力取得了不同程度的成功，那些更晚，而不是更早(因此，在几个应用程序已经开发)更成功。