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

Question

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

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

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

Answer 1

这取决于复杂的“项目”和“合同”域名。通过回答以下问题，我希望您能够做出正确的决定：

1. 隔离变更视角：您是否希望某个域的要求变更独立或更频繁，而另一个域变更？
2. 团队设置视角：您是否希望这些功能由单独/多个团队实施？他们是否能够在不了解其他团队的领域的情况下独立工作？
3. 技术观点：您是否希望通过不同的技术更有效地实施项目和合同域？
4. 数据一致性视角：您能接受项目和合同之间的最终一致性吗？
5. 非功能性需求视角：这些服务的性能和可用性要求是否不同？
6. 技术风险观点：您是否已经在团队内部拥有分布式系统和必要的专业知识？
7. 凝聚力观点：尝试对服务进行建模，其中一个是完全独立于运行时的另一个？相互依赖是高凝聚力的标志，也是不同服务的不良候选者
8. 服务客户视角：这些服务会有不同的客户吗？是否会被其他服务访问？

如果几乎​​所有问题的答案都是“是”，那么继续使用2个微服务。我认为很可能不是。