代码之家  ›  专栏  ›  技术社区  ›  Tomasz Jaskuλa

松散耦合域模型建模

  •  4
  • Tomasz Jaskuλa  · 技术社区  · 15 年前

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

    为什么?因为每个公司都以不同的方式处理人力资源,这取决于公司的规模等等。

    当然,我们可以识别人力资源领域中的社区实体,例如:工作、提供、合作者、技能等,但它们与客户A和客户B的链接方式不同。 因此,从领域模型的角度来看,我们不能说实体A引用了具有技能集合的实体B,因为对于另一个客户来说,这不是真的。

    即使对于80%的客户,我们可以设计一个能够满足90%需求的模型,我们也不会牺牲其他客户,另一方面,我们希望有一个能够进行特定开发以解决不同问题的产品。

    我们研究了BPM解决方案,但这不符合我们的需求。另一方面,我无法想象你如何处理我们需要的事情。实际上,实体之间的链接应该在运行时从每台客户机的一种参数、XML等“完成”。我们不需要编写另一个应用程序的代码,因为域模型发生了轻微的变化。如果没有Propper域模型,这可能是完全疯狂的,但是基于消息传递的东西可以帮助我们。

    希望你能考虑一下。你是如何处理这种情况的。

    谢谢,

    2 回复  |  直到 15 年前
        1
  •  4
  •   Mark Seemann    15 年前

    域模型的目的是封装公共 行为和关系 . 虽然您可以(并且应该)松散地耦合您的实现,但是对于您如何实现配置驱动有一些限制。

    如果您不断地将其推向越来越多的可配置性,在某一点上,它将不再是一个域模型,而是成为一个 框架 . 然后可以使用框架定义特定的域模型。

    写一个框架真的,真的很难,所以我不认为用这个明确的目标来启动一个项目是一个可行的计划。

    如果可以的话,从一个公共的代码库开始,每当您收到一个特定于客户的请求时,重构内核,这样您就可以将客户特性作为 插件 .

    大量的 时间、运气和技能 可以 能够 发展 那颗核变成了 特定于域的框架 .

        2
  •  1
  •   Pablo Castilla    15 年前

    “魔法产品问题”,我们都在寻找其中的一个。我刚刚成功地使用了SOA。我们很好地识别了服务,后来我们改变了一些业务流程或业务服务。

    我想说的是,你永远无法通过配置来解决所有的差异,我应该努力在一个简单的适应性中做一个好的代码思考,但是,imho,“神奇的产品”是不可能的。