如何在我的域严重依赖其他域的情况下削减整体?

时间:2019-07-16 21:57:13

标签: domain-driven-design microservices

我目前正在学习微服务,因为在我工作的公司中,我们会将庞大的整体拆分为微服务。

我们的应用程序中有很多业务逻辑,但是该规则基本上可以验证来自许多不同域的数据并相应地处理这些数据的状态。

当然,我们的域拥有自己的数据,但我什至敢说我们依赖不同域中60%到70%的数据,这使我们的域成为了一个聚合器。

我创建了一个小图来说明它: enter image description here

因此,就像我之前说的那样,我的域(域A)具有许多业务逻辑来验证来自所有这些不同域的数据和状态。然后,在执行此验证之后,请采取适当的操作并将其结果保存在数据库中。

我觉得自己已经走到了尽头,因为我读过几篇文章,介绍了如何分解整体,但是我没有很好的例子说明这种情况。

所以我问你们,您有什么建议要告诉我吗? :) 谢谢!

2 个答案:

答案 0 :(得分:2)

在DDD中,有界上下文近似于微服务。图中不同的 domain 可能是有界上下文。

您肯定不希望来自各个BC的概念相互污染,因为您最终将陷入一团糟。

但是,在一个地方,您可能会遇到这个问题,那就是集成/编排。在这里,您应该将这种关注点当作与业务流程或集成相关的单独BC。

例如,假设您有一个Assets域和一个Accounting域。两者应该一无所知。但是,当您停用某项资产(例如,将一台巨大的机器将石头磨成石头)时,如果该资产尚未达到其使用寿命,则可能需要使会计域记录一些冲销值。在此中,您将集成进程的各个位,并使用进程管理器管理状态。尽管过程管理器和相关状态可能属于Assets BC,但是AssetsOrchestration BC可能同时使用AssetsAccounting BC中的对象。通常,您会尝试使用某种消息传递基础结构(但使用YMMV)将这种交互限制为例如消息。

答案 1 :(得分:0)

一个很好的起点可能是萨姆·纽曼(Sam Newman)的Microservice Decomposition Patterns

大约18分钟的谈话中,纽曼提供了这种模式:

  • 在整体中,确定功能的粗略模块。
  • 绘制依赖关系图
    • 好的,您的依赖图包含循环。那不好,您想要一个非循环图。因此,在图表上进行迭代,直到您能够消除循环为止。完成此操作之前,请不要通过
  • 确定没有入站依赖关系的候选模块-您需要其他没有依赖的位。
  • 选择一个,看看是否可以重新设计系统以允许您独立于整体而部署该模块。