Hel*_*123 5 domain-driven-design cqrs
我有一个问题，关于验证跨界上下文中实体的存在时的最佳实践是什么。这在 DDD 中是一种有效的方法吗？BC 本质上应该是独立的部署（即您不应该依赖于另一个可能不可用的 BC）。
我的项目中有 2 BC - 配料和食谱。该公司销售散装原料，但也销售使用上述原料的预先配置的食谱。现在这些是独立的 BC，每个都有自己的成分实体。
配方是一个聚合根，具有成分列表的子实体。在将某种成分添加到Recipe BC的成分列表之前，验证该成分是否存在于Ingredient BC中是否有意义？
成分只能通过成分 BC 进行修改，其中将发布事件，并且配方 BC 将订阅并更新其自己的成分以进行任何更改（即价格/名称）。为了使其有效，该成分必须是有效的。那么如何保持这些BC之间的一致性呢？我是否将域服务注入到配方 BC 中并在添加成分之前验证成分是否存在？我也在使用 CQRS，因此我可以将服务直接注入到处理程序中，而不是用于创建食谱的工厂（或者这是使用域服务的正确方法吗？）。
有点迷失在这一点上，如果这是一个合理的担忧。
一般来说，您的食谱应该只关心成分的唯一标识符，而不是其详细信息。配方的一致性不需要成分的详细信息。
我假设某些操作（例如用户与 UI 交互）会将成分添加到食谱中。我还假设可以添加的成分来自仅返回有效成分的查询。除非你有理由担心某事/某人会破坏这个过程，否则你可能会花时间解决一个不太可能成为真正问题的问题。
如果这实际上是一个真正的问题，那么是的，您可以在添加成分之前验证它们是否存在。然而，这可能最好在命令验证器中靠近配方 BC 的边界处完成。
有界上下文是概念性的——它（通常）不由单个类表示。我提到这个是因为你问
我是否将域服务注入到配方 BC 中？。。？
你并没有真正“注入”BC。同样，如果您确实需要此验证，您可能会拥有一个验证类，该验证类通过 API 或数据库查询成分 BC 以确保其存在。
食谱 BC 将订阅并更新其自己的成分以应对任何变化（即价格/名称）。
这应该是没有必要的。该食谱引用了其每种成分，因此当您查询食谱时，您会查询成分列表以及这些成分的详细信息。根据您的设置，这可能是 SQL 连接或其他方式（根据您的设置，可以通过多种不同的方式来完成此操作）。通常，您应该避免在收据 BC 中缓存成分详细信息，除非您对性能有特定的担忧。缓存总是会增加复杂性。
当您继续使用 CQRS 时，您会发现的一件事是，许多您通常认为是“命令问题”的问题实际上在查询方面更容易解决。