建模松散耦合的域模型答案

【问题标题】：Modeling loosely coupled domain model建模松散耦合的域模型
【发布时间】：2011-01-20 10:48:41
【问题描述】：

这个问题并不真正涉及 DDD，但想知道是否有任何方法可以对松散耦合的域模型进行建模。我的意思是什么？我为软件人力资源编辑工作，我们计划从头开始一个新的应用程序。我们对我们为 150 个客户所做的所有项目进行了审计，事实是，从 DDD 的角度来看，我们不能说存在一个有效的域模型。

为什么？因为每个公司处理人力资源的方式都不同，具体取决于公司的规模等等。

当然，我们可以识别 HR 领域中的公共实体，例如：工作、offer、协作者、技能等，但是对于客户 A 和客户 B，它们的链接方式不同。因此，从领域模型的角度来看，我们不能说实体 A 引用了具有一系列技能的实体 B，因为对于其他客户而言，这不是真的。

即使我们可以为 80% 的客户设计一个模型来满足 90% 的需求，我们也不会牺牲其余的客户，另一方面，我们希望有一个产品没有进行特定的开发来解决不同的问题担心。

我们研究了 BPM 解决方案，但这并不符合我们的需求。另一方面，我无法想象你如何处理我们需要的东西。事实上，实体之间的链接应该在运行时根据每个客户端的某种参数、xml 等“完成”。我们希望不必编写另一个应用程序，因为域模型略有变化。如果没有合适的域模型，这可能是完全疯狂的，但基于消息传递的东西可以帮助我们。

想听听您对此的看法。你是如何处理这种情况的。

谢谢，

【问题讨论】：

标签： .net architecture domain-driven-design

【解决方案1】：

领域模型的目的是封装常见的行为和关系。虽然您可以（并且应该）松散耦合您的实现，但您可以如何实现配置驱动是有限度的。

如果你不断将其推向越来越多的可配置性，在某个时候它将不再是一个领域模型，而是成为一个框架。然后，您可以使用该框架来定义特定的领域模型。

编写框架真的非常非常困难，所以我认为以这个明确的目标开始一个项目不是一个可行的计划。

如果可以，从通用代码库开始，每次收到客户特定请求时，重构内核，以便您可以将客户功能实现为插件。

凭借大量的时间、运气和技能，您可能能够将该内核发展成为一个特定领域的框架。

【讨论】：

我知道通过配置不可能做到所有事情。挑战在于制作一个软件，您将能够从头到尾查看流程/工作流程。使用插件，当您有超过 150 个客户时，问题就来了。因此，保留每个客户的插件版本是很重要的。要知道插件是否与应用程序的其余部分兼容，这在当时的诅咒中得到了改进。处理来源。在我们的例子中，它是我们现在所拥有的，它是一个地狱。还有其他问题，对于每个客户，域逻辑将分散在应用程序和插件中。
关于插件等的兼容性问题最好通过持续集成和大量自动化测试来解决。

【解决方案2】：

“神奇的产品问题”，我们所有人都在寻找其中之一:)。我刚刚使用 SOA 成功完成了一项工作。我们在识别服务方面做得很好，后来我们只是稍微改变了编排或业务服务。

我想说的是，您永远无法通过配置解决所有差异，我应该努力在易于适应的情况下进行良好的代码思考，但是，恕我直言，“神奇产品”是不可能。

【讨论】：