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

Question

我有 2 个域对象：项目和合同。一个项目可以有许多合同，因此在数据库中它被建模为经典的一对多关系。我们的问题是：您如何在微服务的上下文中对上述内容进行建模？您 (a) 是否有 2 个微服务 ProjectService 和 ContractService？或 (b) 您是否有一个包含项目和合同的 ProjectService？

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

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

Answer 1

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

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

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