定义运行时责任隔离

在您作为软件开发人员的生活中，总是需要对动态运行时行为进行建模的时间。

规则引擎，业务流程自动化，KPI计算。

这些都是域的示例，您可以在其中始终找到两个固定的后续时刻：

使用规则引擎。

有人需要定义一个规则，然后才能在稍后的某个时间执行该规则。

现在让我问一个问题：

规则的定义及其运行时行为应该在一个地方建模吗？

我曾经那样做，这很痛苦。

表示规则之类的类最终将具有仅在两个时刻之一（定义或运行时）中使用过的属性和方法。

当然，该模型正在运行，但是混乱和混乱。

我一直在尝试规范两个用例之间的属性和行为。

在忽略无关部分的同时，引入变化的认知负荷也在不断增加。

我开始认为，有很大的机会可以更深入地了解模型。

确实，不久之后我发现了它。

我意识到， 同一实体在两个不同的时刻使用时，需要两个不同的独立模型 。

换句话说：

当域要求动态的上下文行为时，您应该始终具有两个单独的模型。 一个用于定义，一个用于运行时。

这实际上是我现在多次看到的模式。

它使我获得了最终的代码工件的精致和优雅，这是我无法通过单一模型策略实现的。

认识到定义某物的时刻与将某物应用于上下文数据的时刻之间的分离，使开发人员在表达一个功能强大的模型时具有相当大的优势，该模型对领域具有更深入的了解，并且是进一步突破的最佳配置。

我认为这个概念非常普遍，可以应用于许多领域。

这就是为什么我渴望给它起个名字的渴望。

最初，我去了Temporal CQRS ，但是尽管上下文不对，我对C和Q仍然在那里并不满意。我也害怕这样的名字会引起混乱。

最终版本来自我，希望保留与CQRS的对偶关系，以便于调用，同时为对偶元素找到合适的名称。

最终，我选择了：

定义运行时责任隔离 。