使用其他聚合中的数据检查命令的有效性 [英] Check command for validity with data from other aggregate
问题描述
我目前正在开发第一个更大的DDD应用程序。目前，它运作良好，但是自从早期以来，我们就一直困扰着我，不能停止思考：
I am currently working on my first bigger DDD application. For now it works pretty well, but we are stuck with an issue since the early days that I cannot stop thinking about:
在我们的某些集合体中，我们继续引用另一个对于整个应用程序来说，聚合根非常重要（基于它们的ID，因此没有硬引用-删除也是基于事件/最终一致性）。现在，当我们创建一个新的实体 Entity1时，我们将发送一个新的CreateEntity1Command，其中包含引用的聚集根的ID。
In some of our aggreagtes we keep references to another aggregate-root that is pretty essential for the whole application (based on their IDs, so there are no hard references - also the deletion is based on events/eventual consistency). Now when we create a new Entity "Entity1" we send a new CreateEntity1Command that contains the ID of the referenced aggregate-root.
现在如何检查此引用的ID是有效的吗？现在，我们通过从其他聚合中读取（而不在此处进行任何修改）进行检查-但是这种方法有点让人感到肮脏。我只想信任命令，因为不能手动输入ID，而必须选择ID。问题是，我们的应用程序是一个Web应用程序，要信任您在那里到达的用户输入并不是真正安全的方法（即使它不是公众可访问的）。
Now how can I check if this referenced ID is a valid one? Right now we check it by reading from the other aggregate (without modifying anything there) - but this approach somehow feels dirty. I would like to just "trust" the commands, because the ID cannot be entered manually but must be selected. The problem is, that our application is a web-application and it is not really safe to trust the user input you get there (even though it is not accessibly by the public).
我是否忽略了针对此问题的任何可能解决方案，还是应该忽略需要有更好解决方案的感觉？
Did I overlook any possible solutions for this problems or should I just ignore the feeling that there needs to be a better solution?
推荐答案
直接聚合到聚合交互是DDD中的反模式。聚合A不应直接向聚合B发送命令或查询。聚合是严格的一致性边界。
Direct Aggregate-to-Aggregate interaction is an anti-pattern in DDD. An aggregate A should not directly send a command or query to an aggregate B. Aggregates are strict consistency boundaries.
我可以想到2种解决方案：假设您有2个聚合根（AR）-A和B。每个AR都有一堆命令处理程序，其中每个命令引发1个或多个事件。您在A中的命令处理程序取决于B中的某些数据。
I can think of 2 solutions to your problem: Let's say you have 2 aggregate roots (AR) - A and B. Each AR has got a bunch of command handlers where each command raises 1 or more events. Your command handler in A depends on some data in B.
-
您可以订阅B引发的事件并保持状态B中的B。您只能订阅指示有效性的事件。
You can subscribe to the events raised by B and maintain the state of B in A. You can subscribe only to the events which dictate the validity.
您可以拥有一个完全独立的服务（S），在A和B之间进行协调。不是直接将您的请求发送到A，而是将您的请求发送到S，后者将负责从B进行查询（以检查引用ID的有效性），然后将请求转发到A。有时也称为流程管理器（PM） 。
You can have a completely independent service (S) coordinating between A and B. Instead of directly sending your request to A, send your request to S which would be responsible for a query from B (to check for validity of referenced ID) and then forward request to A. This is sometimes called a Process Manager (PM).
例如，在您创建新实体 Entity1的情况下，将此请求发送给其工作将是验证您请求中的数据是否有效，然后将您的请求路由到负责创建 Entity1的聚合。向此PM发送一个新的CreateEntity1Command，其中包含引用的聚集根的ID，该PM使用引用的AR的ID来确保其有效，如果有效，则只有它会将您的请求转发。
For Example in your case when you are creating a new Entity "Entity1", send this request to a PM whose job would be to validate if the data in your request is valid and then route your request to the aggregate responsible for creating "Entity1". Send a new CreateEntity1Command that contains the ID of the referenced aggregate-root to this PM which uses ID of the referenced AR to make sure it's valid and if it's valid then only it would pass your request forward.
有用链接： http：// microservices.io/patterns/data/saga.html
这篇关于使用其他聚合中的数据检查命令的有效性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
