c# - 将Masstransit包装为CQRS实现是一种好习惯吗？

Closed. This question is opinion-based。它当前不接受答案。
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。
                        
                        2年前关闭。
                                                                                            
                
        
我宁愿有一个单独的CommandBus和EventBus以及ICommandHandler<TCommand>和IEventHandler<TCommand>，这样一个OrderEventHandler类看起来像：

public class OrderEventHandler :
    IEventHandler<OrderPlaced>,
    IEventHandler<OrderRegistrantAssigned>,
    IEventHandler<OrderTotalsCalculated>,
    IEventHandler<OrderConfirmed>,
    IEventHandler<OrderExpired>,
    IEventHandler<SeatAssignmentsCreated>,
    IEventHandler<SeatAssigned>,
    IEventHandler<SeatAssignmentUpdated>,
    IEventHandler<SeatUnassigned>
{
    public void Handle(OrderPlaced @event){...}
    .
    .
    .
}

可能的解决方案是在Masstransit基础结构和我的CQRS之间提供采用者（例如ConsumerToHandlerAdopter<T>仅公开我通常需要的上下文详细信息）。

但是由于我是Masstransit的新手，所以我无法解决以后可能要处理的问题。

所以我的问题是：
通常，包装Masstransit以便我处理自己的基础结构是否值得？

最佳答案

我们使用MassTransit广泛实现CRQS，但仅用于命令处理。

多次讨论了不使用消息传递基础结构同步写入和读取模型的原因。主要原因是您有机会保留更改而不发布事件，因为这是基础结构的两个不同部分。除非您使用DTC之类的东西，否则您将无法保证模型之间的一致性。

同样，在这一点上，我们还希望远离“上帝处理程序”类。 MassTransit特别擅长通过将每个消费者划分到一个单独的类来执行SRP（单一责任原则）。

对于一般的基于域事件的集成（响应事件处理），我们还使用MassTransit。

您还可以具有实现多个消息接口的事件，这样您将拥有更全面的事件处理：

public interface CustomerRegistered
{
    string FullName { get; }
}

public interface OrderPlaced
{
    string Reference { get; }
    List<OrderLine> Lines { get; }
}

public class NewCustomerOrderedStuff : CustomerRegistered, OrderPlaced
{
...
}

public class CustomerRegisteredConsumer : IConsumer<CustomerRegistered>

public class OrderPlacedConsumer : IConsumer<OrderPlaced>

这些消费者中的每一个都会有不同的关注点，并且可以生活在一个单独的有限上下文（服务）中。