假设我们正在开发一个带有模块(销售、会计、采购等)的应用程序。销售模块是可用的基本/主要模块,而会计模块是一个互补模块。-.想到的另一个解决方案是添加SalesIntegrations类(ProductAccount等),以补充前面描述的Product,使其独立。但这个解决方案听起来并不像a Product has a list of Accounts那样“自然”。
据我所知,做DDD意味着预先了解整个业务规则的概念。
然而,当我们试图从功能上将整体划分为微服务时,我们看到了业务逻辑和数据实际上是如何交织在一起的。当我们坐在一个大型数据库之上,并且能够进行大型关系连接时,这不是问题。但对于微服务,这就成了一个问题。一种解决方案是使微服务-A转到5-10个其他微服务以获取必要的数据(这相当于DB view with join)。另一种解决方案是让微服务-A监听来自5-10个其他服务的事件,并将相关内容填充到本地存储中(这相当于物化视图)。许多文章提倡第二种解决方案-即类似于事件采购、编排等的解决方案。
如