我目前正在学习微服务,因为在我工作的公司中,我们会将庞大的整体拆分为微服务。
我们的应用程序中有很多业务逻辑,但是该规则基本上可以验证来自许多不同域的数据并相应地处理这些数据的状态。
当然,我们的域拥有自己的数据,但我什至敢说我们依赖不同域中60%到70%的数据,这使我们的域成为了一个聚合器。
因此,就像我之前说的那样,我的域(域A)具有许多业务逻辑来验证来自所有这些不同域的数据和状态。然后,在执行此验证之后,请采取适当的操作并将其结果保存在数据库中。
我觉得自己已经走到了尽头,因为我读过几篇文章,介绍了如何分解整体,但是我没有很好的例子说明这种情况。
所以我问你们,您有什么建议要告诉我吗? :) 谢谢!
答案 0 :(得分:2)
在DDD中,有界上下文近似于微服务。图中不同的 domain 可能是有界上下文。
您肯定不希望来自各个BC的概念相互污染,因为您最终将陷入一团糟。
但是,在一个地方,您可能会遇到这个问题,那就是集成/编排。在这里,您应该将这种关注点当作与业务流程或集成相关的单独BC。
例如,假设您有一个Assets
域和一个Accounting
域。两者应该一无所知。但是,当您停用某项资产(例如,将一台巨大的机器将石头磨成石头)时,如果该资产尚未达到其使用寿命,则可能需要使会计域记录一些冲销值。在此层中,您将集成进程的各个位,并使用进程管理器管理状态。尽管过程管理器和相关状态可能属于Assets
BC,但是AssetsOrchestration
BC可能同时使用Assets
和Accounting
BC中的对象。通常,您会尝试使用某种消息传递基础结构(但使用YMMV)将这种交互限制为例如消息。
答案 1 :(得分:0)
一个很好的起点可能是萨姆·纽曼(Sam Newman)的Microservice Decomposition Patterns。
大约18分钟的谈话中,纽曼提供了这种模式: