问题并不是真正关注DDD，而是想知道是否有任何方法可以模拟松散耦合的域模型。我的意思是什么？我为一个软件HR编辑工作，我们计划从头开始一个新的应用程序。我们对我们为150位客户所做的所有项目进行了审核，事实上我们不能说从DDD的角度来看有一个有效的域模型。
为什么？因为每家公司都会以不同的方式处理人力资源，具体取决于公司的规模等等。
当然，我们可以识别人力资源领域的社区实体，如：工作，提供，合作者，技能等，但它们与客户A和客户B的关联方式不同。 因此，从域模型的角度来看，我们不能说实体A具有对实体B的引用，实体B具有一系列技能，因为对于另一个客户而言它不是真的。
即使我们80％的客户能够设计满足90％需求的模型，我们也不会牺牲其他客户，另一方面也希望有一个产品能够通过特定的开发来解决不同的需求顾虑。
我们研究了BPM解决方案，但这并不符合我们的需求。另一方面，我无法想象你如何处理我们需要的东西。事实上，实体之间的链接应该在运行时从每种客户端的一种参数，xml等“完成”。我们不想编写另一个应用程序，因为域模型稍有变化。如果没有适当的域模型，这可能会非常疯狂，但基于消息传递的东西可以帮助我们。
希望你对此有所了解。你是怎么处理这种情况的。
谢谢，
答案 0 :(得分：4)
域模型的目的是封装常见的行为和关系。虽然您可以（而且应该）松散地结合您的实现，但是您可以通过配置驱动来实现它。
如果您继续将其推向越来越多的可配置性，那么在某个时刻它将不再是域模型而是成为框架。然后，您可以使用框架来定义特定的域模型。
编写框架确实非常困难，所以我认为用这个明确的目标启动项目并不是一个可行的计划。
如果可以，请从公共代码库开始，每次获得客户特定请求时，重构内核，以便将客户功能实现为插件。
有很多时间，运气和技能，您可能能够将内核发展为特定于域的框架
答案 1 :(得分：1)
“神奇的产品问题”，我们所有人都在寻找其中的一个:)。我刚刚使用SOA做了一个成功。我们做了很好的工作来识别服务，后来我们只是改变了一些管弦乐或商业服务。
我想说的是，你永远无法通过配置解决所有差异，我应该努力在一个简单的适应性中做一个好的代码思考，但是，恕我直言，“魔术产品”是不可能的。