域是否应该访问另一个系统的应用服务?

时间:2011-07-01 14:16:06

标签: architecture service domain-driven-design distributed-system

跨两个系统:系统A的域可以调用系统B的应用程序服务/远程外观吗?

例如,如果订购系统在其域中有一个订单实体,那么该订单实体的验证方法是否应该调用库存服务的应用服务来检查库存中是否有足够的产品来履行订单?

我的直觉是,这不是正确的做事方式。

这是之前一个相当复杂的问题的简化版本: Integration between various Domain Driven Design systems 您并不建议您参考上一个问题。

2 个答案:

答案 0 :(得分:1)

首先,考虑您的架构是值得的。为什么您的域逻辑必须直接挂钩到另一个域?它是否可以消耗其他域发布的数据?如果没有,我们真的在谈论两个不相交的领域,还是它们真的属于同一个有界的背景?

可能是其他系统是封闭系统,因此您无法扩展它。也可能是其他系统不根据事件发布其数据,并且您只能通过API访问它。在这种情况下,最好在域模型中使用代理。也就是说,您的域逻辑应包含连接到远程系统的代理(代理),但其行为类似于本地。这甚至封装了实际逻辑/数据不是本地的事实。

答案 1 :(得分:1)

在我看来,有很多方法可以解决这个问题。 首先,为什么您的域模型需要访问其他域模型?

a)制作更复杂的领域模型==>此域模型可以是Service层中的用户,用于创建ViewModel。 ==>这个viewModel将返回给客户端。

在这种情况下,组装应该参与服务层,而不是域层。换句话说,向您的域模型和相邻服务发送一些请求,从中获取结果,在特定的ViewModel中将它们组合在一起,最后将结果返回给客户端。

b)您的域模型负责检查某些业务规则。假设其中一些系统将在其他系统中进行检查,因此您决定是否可以访问域模型中的相邻系统。

考虑到您的域模型的责任 - 属于您的系统 - 正在检查有关您的系统的一些规则,而不是检查其边界之外的任何规则。我的意思是,您的域模型不应该访问其他系统域。它在这些系统之间产生了一些依赖性它不是基于面向服务架构的好方法。这是针对松散耦合的设计。相反,您应该在服务层中的这些系统之间进行协调。服务层向不同的系统发送一些请求并从中获得一些响应。现在最终决定将根据整体结果制定。

相关问题