领域驱动设计最佳实践推荐
我有一组数据，这些数据要么在数据库中，要么在跨界服务中，比如说一堆活跃产品。当我对应用程序进行查询时，业务规则规定我必须在提供响应之前检查它是否是该外部服务中的产品之一，
我正在考虑流畅的验证查询验证请求，并通过依赖注入将中介器传递给验证器。这意味着现在我可以通过发出另一个查询来调用外部服务，并在请求到达处理程序之前验证该请求。
图
RequestQueryA -> 验证管道 ->验证器->中介者与 RequesQueryB -> B处理程序-> B 响应->验证器->验证管道下一个->处理程序->答：
但不确定这是否是一个好的做法。请指教
I have set of data which is either in database or cross boundary service let's say bunch of active products. When I make a query to application there is business rule says I have to check whether it is one of the products in that external service before providing response
I'm thinking fluent validation query validation request and pass in mediator to the validator by dependency injection. This means now I can call the external service with issuing a another query and validate the request before it hits the handler.
Diagram
RequestQueryA ->Validation pipe -> Validator -> mediator with RequesQueryB -> B handler-> B Response-> Validator-> Validation pipe next->A handler-> AResponse
But not sure whether it's a good practice. Please advise
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
跨越边界是一个基础设施问题，需要基础设施的答案，而不是真正的业务规则。
您正在做的是跨界上下文查询，并且有两种方法可以实现此目的：
在 API 组合架构中，您不会操纵来自跨边界服务的数据。在两个服务前面添加一个 API 网关并让它进行聚合。
在 CQRS 架构中，您的服务之间需要有异步通信机制，以便您当前的服务可以从外部有界上下文接收信息并维护本地副本。然后，您的服务可以从两个上下文返回数据，尽管仅对本地数据具有权威性。
Crossing the boundaries is an infrastructure concern that requires an infrastructure answer, not really a business rule.
What you are doing is cross bounded context query and you have two approaches for doing that:
In an API composition architecture, you do not manipulate data from cross boundary service. Add an API gateway in front of both services and have it do the aggregation.
In a CQRS architecture, you need to have an asynchronous communication mechanism between your services, so your current service can receive information from that external bounded context and maintain a local copy. Then your service can return data from both contexts, although only authoritative for what is local.