イベントの非プリミティブ型

Question

イベントを処理する場合、通常、プリミティブのみで構成された非常に単純な値のオブジェクトの例が使用されます。 しかし、もっと情報が必要なイベントはどうですか？これらのケースを処理するために特定の構造を作成することは許可されていますか？

namespace Events { 
    public class BlueTrainCleaned 
    { 
     Datetime start 
     Datetime end 
     Carriage[] Carriages 
    } 

    public class Carriage 
    { 
     string Descrizione 
     int Quantity 
    } 
} 

キャリッジクラスはイベント名前空間の一部であり、複雑なロジックや何もありません。

が、私は別のイベントがあった場合：

public class RedTrainCleaned 
{ 
    Datetime start 
    Datetime end 
    Carriage[] Carriages 
} 

をキャリッジは、第二イベントのインタフェースの一部になります。同じ "イベント値オブジェクト"を持つ40または50のイベントを考えてみると、私のプロジェクトはこのオブジェクトに大きく結びついていることになります。それは私には良く見えませんが、これを避けるために私は何ができますか？私のドメインの分析に何かがうまくいっていないという警告ですか？あなたの助けのための

おかげで、

Answer 1

標準Carriageがあなたのドメインにどのように標準であるかによって決まります。 1つのイベントで変更された場合は、他のイベントでも変更する必要がありますか？

私はAddressの例を考えると思います。ドメイン内ではかなり標準的ですが、アドレス情報を含むイベントを発生させている場合は、イベントオブジェクトにそのイベントを含めることが理にかなっていると思います。こうすることで、郵便番号のZIP + 4拡張が必要になることがわかった場合は、Addressクラスに新しいフィールドを追加し、そのプロパティを将来のイベントで使用できるようにすることができます。私は1つの場所で変更を行い、将来のイベントに利用できるようにすることができます。

Carriageは、さまざまなイベントで異なるものを意味する場合は、含めるべきではないかもしれないし、代わりにあなたのイベントでそれを平坦化してください。しかし、Carriageが本当にあなたのドメイン内のユビキタスな定義なら、あなたのイベントクラスにそれを含めることは大丈夫だと思います。

私が聞いていて楽しいかもしれませんが、本当に「依存している」と思います。

こちらがお役に立てば幸いです。がんばろう！！

Answer 2

別のクラスライブラリプロジェクトは、メッセージクラス（DTOの）を含むように作成することができます。このプロジェクトは理想的には、ソリューションの他のプロジェクトに依存してはならず、シリアライズ可能なPOCOだけを含むべきです。 このケースでは、DTOライブラリを共有するだけで、依存性は最小限に抑えられます。