CQRS実装のためにMasstransitをラップするのは良い方法ですか？

Question

ようOrderEventHandlerクラスが見えるように私はむしろCommandBus別々とEventBusともICommandHandler<TCommand>とIEventHandler<TCommand>を持っているでしょう：

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をラップしていますか？

Answer 1

私たちは、MassQransitを使用してCRQSを広範囲に実装していますが、コマンド処理のためにのみ使用しています。

メッセージングインフラストラクチャを使用して書き込みモデルと読み取りモデルを同期させない理由は、何度も説明されています。主な理由は、変化を持続させ、イベントを公開しないということです。これは、インフラストラクチャの2つの異なる部分であるためです。 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> 

をそして、それらの消費者のそれぞれが異なる懸念がありますし、囲まれた独立した中で生きることができます文脈（サービス）。