微服务:如何建模相关的域对象？

我有2个域对象:项目和合同.一个项目可以有很多合同,所以在数据库中它被建模为一个典型的一对多关系.我们的问题是:你如何在微服务环境中对上述模型进行建模？你(a)有2个微服务ProjectService和ContractService吗？或(b)您是否有一个包含项目和合同的ProjectService？

我们认为答案(a)(即2个微服务ProjectService和ContractService)意味着必须调用2个服务来检索和保存完整的Project对象层次结构.另一方面,答案(a)完全将项目与合同分离,这在理论上可能是一件好事,但实际上没用,因为合同在没有项目的情况下不能在逻辑上存在.

这里的正确方法是什么？答案是(a)纳米服务反模式的一个例子吗？

这取决于复杂的"项目"和"合同"域名.通过回答以下问题,我希望您能够做出正确的决定:

隔离变更视角:您是否希望某个域的要求变更独立或更频繁？

团队设置视角:您是否希望这些功能由单独/多个团队实施？他们是否能够在不了解其他团队的领域的情况下独立工作？

技术观点:您是否希望通过不同的技术更有效地实施项目和合同域？

数据一致性观点:您能接受项目和合同之间的最终一致性吗？

非功能性需求视角:这些服务的性能和可用性要求是否不同？

技术风险观点:您是否已在团队内部拥有分布式系统和必要的专业知识？

凝聚力透视:尝试对服务进行建模,其中一个是完全独立于运行时的另一个？相互依赖性是高凝聚力的标志,也是不同服务的不良候选者

服务客户视角:这些服务会有不同的客户吗？他们都会被其他服务访问吗？

如果几乎所有问题的回答都是"是",那么继续使用2个微服务.我认为最有可能的不是.