微服务共享域层

通常，微服务架构采用“无共享”概念，这意味着您的代码库应该理想地分开。是的，这意味着您将编写更多代码，但会使您的微服务更易于管理，解耦并且可能更轻松。

另外，关于DDD-part做的问题，你应该努力在你的应用程序中保持良好定义的边界，这意味着你不应该害怕在不同的有界上下文中拥有“冗余”实体，因为相同的概念通​​常意味着不同的东西到您的应用程序的不同域区域。

保持“ERP”主题，您希望应用程序的“订单放置”上下文在“产品”实体上具有与“税”上下文完全不同的视图。将它们保存在不同代码库中的不同上下文中将允许您使用更高级别的内聚来建模更小的聚合，这将更少地耦合到模型的其他构造，从而使您的微服务变得更容易。

我的问题是：微服务共享项的边界是什么，有多糟糕？

直到几年前，将边界定义为微服务是很复杂的，因为根本没有达成如何实现这一点的协议，但埃文斯在几年前对其进行了分类：

GOTO 2015 - DDD＆amp;微服务：最后，一些边界！埃里克埃文斯

微服务也遵循SOA的四个租户，并且考虑到他们的业务范围不同，同样考虑分布式系统的9个谬误。请记住，微服务架构应遵循无共享架构，因此服务并不真正共享实体，他们所做的是订阅消息，通常在总线中，并存储它们所在的数据的本地副本。这显然引入了另一个概念，称为最终一致性，并且取决于您的业务需求，如果在您的整体设计中，可能会也可能不会。