1 soa domain-driven-design solid-principles microservices
我对微服务架构有疑问。我们正在开发一个 ERP,有几个微服务,如人力资源、身份、订单等。
我们为所有这些层通用的实体实现了一个共享域层,包括公司、位置和一些值对象的抽象(接口)。
我的问题是:微服务的共享项的边界是什么,这有多糟糕?
在这种情况下,这些共享实体对于每个微服务都是相同的,这样有助于我们编写更少的代码,但同时会创建一个小的耦合级别。
通常微服务架构采用“无共享”概念,这意味着您的代码库应该理想地分开。是的,这意味着您将编写更多代码,但将使您的微服务更易于管理、解耦并且可能更轻。
此外,关于 DDD 部分做这个问题,你真的应该努力在你的应用程序中保持明确定义的边界,这意味着你不应该害怕在不同的有界上下文中拥有“冗余”实体,因为相同的概念通常意味着不同的东西应用程序的不同领域。
继续“ERP”主题,您希望应用程序的“Order Placeing”上下文对“Product”实体的视图与“Tax”上下文的视图完全不同。将它们保持在不同代码库中的不同上下文中将使您能够以更高的内聚度对较小的聚合进行建模,从而减少与模型的其他构造的耦合,从而使微服务的发展变得更加容易。