soa - 微服务:如何建模相关领域对象？

Question

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

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

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

Answer 1

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

变更隔离的观点:您是否期望一个领域的需求变化是独立的，还是比另一个领域更频繁？

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

技术角度:您是否希望使用不同的技术更有效地实现项目和契约(Contract)领域？

数据一致性观点:你能接受项目和契约(Contract)的最终一致性吗？

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

技术风险视角:团队内部是否已经具备分布式系统和必要的专业知识？

内聚视角:尝试对服务建模，其中一个在运行时是否完全独立于另一个？相互依赖是高内聚和不同服务的不良候选者的标志

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

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