DDD-验证实体在其他有界上下文中的存在

问题描述 投票:0回答:1

我有一个最佳实践,那就是在跨边界上下文中验证实体是否存在时的最佳实践。这在DDD中甚至是有效的方法吗? BC本质上应该是独立的部署(即,您不应该依赖于另一个可能不可用的BC)。

我的项目中有2 BC-成分和食谱。该企业不仅销售散装原料,而且还使用上述原料预配置配方。现在这些都是独立的BC,每个BC都有自己的成分实体。

配方是一个聚合根,它具有成分列表的子实体。在将其添加到Recipe BC中的成分列表之前,先验证一下Ingredient BC中是否存在某种成分?

只能通过将要发布事件的成分BC来修改成分,并且成分BC将订阅并更新其自己的成分以进行任何更改(即价格/名称)。为了使其有效,成分必须是有效成分。那么,如何保持这些BC之间的一致性?在添加BC之前,是否将域服务注入到配方BC中并验证成分的存在?我也正在使用CQRS,因此我可以将服务直接注入处理程序中,而不是将工厂注入创建菜谱的工厂(或者这是使用域服务的正确方法吗?)。

因此而遗失,如果这是一个有效的关注。

domain-driven-design cqrs
1个回答
0
投票

通常来说,您的食谱应该只关心成分的唯一标识符,而不是其详细信息。配方不需要一致的成分详细信息。

我会假设某些操作(例如,用户与U​​I交互)会将成分添加到配方中。我还要假设可以添加的成分来自仅返回有效成分的查询。除非您有理由担心某个人/某人会破坏此过程,否则您可能会花时间解决不太可能是真正问题的问题。

如果实际上这是一个真正的问题,那么可以的,您可以在添加成分之前验证它们是否存在。但是,最好在命令验证器中在食谱BC的边界附近完成此操作。

有界上下文是概念性的-通常(不是)由单个类表示。我提到这个是因为你问

我是否将域服务注入到配方BC中。 。 。 ?

同样,如果您do需要此验证,则可能会有一个验证类,该验证类通过API或数据库查询成分BC以确保其存在。

BC食谱将订阅并更新其自己的成分以进行任何更改(即价格/名称)。

这没有必要。食谱对每种成分都有参考,因此在查询食谱时,您会同时查询成分列表和这些成分的详细信息。根据您的设置,这可以是SQL连接或其他方式(根据您的设置,可以有许多不同的方式来完成此操作)。除非您对性能有特别的担心,否则通常应该避免在Receipt BC中缓存成分详细信息。缓存总是增加复杂性。

您在继续执行CQRS时会发现的一件事是,通常被认为是“命令问题”的许多问题实际上在查询方面更容易解决。

© www.soinside.com 2019 - 2024. All rights reserved.