2011-01-28 13 views
2

EvansのプロジェクトをサンプルDDDプロジェクトで見ているうちに、CargoエンティティではEvanが値オブジェクトであるtracknumberを使用しています。なぜ彼は平文を選択しなかったのですか?string tracknumberではなく、identityの値オブジェクトを選択しますか?ここエヴァンスからの抜粋です:値オブジェクトをエンティティ内の識別子として使用する

public class Cargo implements Entity<Cargo> { 

    private TrackingId trackingId 
} 

public final class TrackingId implements ValueObject<TrackingId> { 

    private String id; 

    /** 
    * Constructor. 
    * 
    * @param id Id string. 
    */ 
    public TrackingId(final String id) { 
    Validate.notNull(id); 
    this.id = id; 
    } 

答えて

2

達成するであろう物事のカップル:

  • はトラッキングIDが
  • nullにすべきではないという論理はトラッキングIDがないことをロジックをカプセル化カプセル化一度変更してください。

プレーンストリングを使用すると、Cargoオブジェクトはこれらのルールを認識する必要があります。バリューオブジェクトアプローチを使用することは、TrackingIdがこれらのルールを保持していることを意味します。

+0

我々は同じことを実現することができます.Netの世界では、readonly変数はコンストラクタを介してのみ設定され、後で変更することはできません。 – kamal

+0

確かですが、ロジックはTrackingIdではなくCargoオブジェクトに存在します。私が作ったのは、Value ObjectのアプローチがTracking Id自体のロジックをカプセル化している点です。 @kamal。 – David

+0

。 TrackingIdは、Cargoオブジェクトが必要としないか、知りたいと思うその他の有用なことを行うこともできます。たとえば、顧客の問い合わせでフォーマットしたり、次の利用可能なID番号を割り当てたり、存在を正当化する以上のトリッキーなロジック。乾杯 – Berryl