我对微服务架构有疑问。我们正在开发一个ERP，并且有一些微服务，例如人力资源，身份，订单等。
我们为所有这些层共有的实体实现了共享域层，包括Company，Location和一些值对象的抽象（接口）。
我的问题是：微服务的共享项目的界限是什么？这有多糟糕？
在这种情况下，每个微服务的那些共享实体都是相同的，这样可以帮助我们编写更少的代码，同时创建一个小的耦合级别。
答案 0 :(得分：3)
通常微服务架构采用＆＃34;什么都不共享＆＃34;概念，这意味着您的代码库应该理想地分开。是的，这意味着您将编写更多代码，但会使您的微服务更易于管理，解耦并且可能更轻。
另外，关于DDD部分做的问题，你应该努力在你的应用程序中保持明确的界限，这意味着你不应该害怕有多余的＆＃34;不同有界上下文中的实体，因为相同的概念通常对应用程序的不同域区域意味着不同的东西。
坚持＆＃34; ERP＆＃34;主题，您期望＆＃34;订单放置＆＃34;您的应用程序的上下文对＆＃34;产品＆＃34;提供了截然不同的观点。实体而不是＆＃34; Tax＆＃34;上下文。将它们保存在不同代码库中的不同上下文中将允许您使用更高级别的内聚来建模更小的聚合，这将更少地耦合到模型的其他构造，从而使您的微服务更容易发展。
答案 1 :(得分：0)
我的问题是：微服务共享项的界限是什么，这有多糟糕？
直到几年前，将边界定义为微服务是很复杂的，因为根本没有达成如何实现这一点的协议，但埃文斯在几年前对此进行了分类：
GOTO 2015 • DDD & Microservices: At Last, Some Boundaries! • Eric Evans
微服务也遵循SOA的四个租户，并且考虑到他们的业务范围不同，分布式系统的相同9个谬误也要考虑在内。请记住，微服务架构应遵循无共享架构，因此服务并不真正共享实体，他们所做的是订阅消息，通常在总线中，并存储它们所在的数据的本地副本。这显然引入了另一个概念，称为最终一致性，并且取决于您的业务需求，如果在整体设计中可能会或可能不会。