DDD / Distinguishing ENTITIES and VALUE Objects


Distinguishing ENTITIES and VALUE Objects (P167)

要約

エンティティとValue Objectを区別する

  • 各オブジェクトを順に取り上げ、それらのアイデンティティもしくは代表値について探ってみる。最初に明確なケース、ついで曖昧なケースを取り上げる。

    Customer
    Customerオブジェクトは、人もしくは企業といった通常の世の中でのエンティティを表す。アイデンティティを明確に持つため、モデルの中においてはエンティティとなる。どのように追跡するかというと、TaxIDを使うことが考えられるが、国際企業では使っていない。既存のシステムに、それぞれの顧客に割り当てられた番号がすでにあるため、それを用いる。

    Cargo
    同一の木枠であっても識別できるので、貨物オブジェクトもエンティティとなる。実際、すべての運送会社でtrackingIDを各貨物に付与している。このIDは自動的に発行され、今回の場合おそらく予約時に顧客に提示される。

    Handling Event and Carrier Movement
    個々の出来事も追跡のために必要である。このオブジェクトは、現実の出来事を反映しており、交換不能なため、エンティティといえる。運搬者の移動も配送スケジュールから得られるコードで識別可能である。なお、Handling Eventは、Cargo IDと完了時刻、タイプの組み合わせで識別可能である。というのも、同じ貨物でも同時に積荷、卸荷が行われるとは限らないからである。

    Location
    同じ名前の場所が同じものとは限らないので、緯度・経度を使えばユニークとなるが、あまり実用的ではなく複雑になる。もっとも、Locationは輸送レーンやドメインに関連する場所のみとなるので、勝手に内部で自動生成されたIDで十分である。

    Delivery History
    配送履歴も交換不能なのでエンティティとなるが、貨物と一対一の関係にあるため、自身のIDは持っていない。このことは後でAGGREGATESのモデルを行う際により明確になる。

    Delivery Specification
    配送明細は、貨物運送のゴールであるが、抽象的なもので、貨物に依存しているわけではない。実際にはある配送履歴の仮説的な状態を表しているのでValue Objectとなる。最終的には、配送履歴が、配送明細を満たすのが目的である。もし貨物を同じ場所に届ける場合、同じ配送明細を共有するが、履歴は共有しない。

    Role and Other Attributes
    Role(役割)は、関連について述べるが、履歴もなく、継続性もないため、Value Objectであり、異なる貨物/顧客の関連で共有される。
    時刻や名前などの他の属性は、Value Objectである。


担当者のつぶやき

  • 要約と言いながら細かすぎました。当日は端折ります。

みんなの突っ込み



まとめ (議事録)