我有2个域对象：项目和合同.一个项目可以有很多合同,所以在数据库中它被建模为一个典型的一对多关系.我们的问题是：你如何在微服务环境中对上述模型进行建模？你(a)有2个微服务
我们认为答案(a)(即2个微服务ProjectService和ContractService)意味着必须调用2个服务来检索和保存完整的Project对象层次结构.另一方面,答案(a)完全将项目与合同分离,这在理论上可能是一件好事,但实际上没用,因为合同在没有项目的情况下不能在逻辑上存在.
这里的正确方法是什么？答案是(a)纳米服务反模式的一个例子吗？
这取决于复杂的“项目”和“合同”域名.通过回答以下问题,我希望您能够做出正确的决定：>隔离变更视角：您是否希望某个域的要求变更独立或更频繁？
>团队设置视角：您是否希望这些功能由单独/多个团队实施？他们是否能够在不了解其他团队的领域的情况下独立工作？
>技术观点：您是否希望通过不同的技术更有效地实施项目和合同域？
>数据一致性观点：您能接受项目和合同之间的最终一致性吗？
>非功能性需求视角：这些服务的性能和可用性要求是否不同？
>技术风险观点：您是否已在团队内部拥有分布式系统和必要的专业知识？
> Cohesion perspective：尝试对服务进行建模,其中一个是完全独立于运行时的另一个？相互依赖性是高凝聚力的标志,也是不同服务的不良候选者
>服务客户视角：那些服务会有不同的客户吗？他们都会被其他服务访问吗？
如果几乎所有问题的回答都是“是”,那么继续使用2个微服务.我认为最有可能的不是.