0

「Always-Valid」エンティティ アプローチ (後で isValid メソッドに対して) の支持者が、コレクションを使用してオブジェクトをモデル化することをどのように提案するかを知りたいです。このアプローチの背後にあるアイデアは本当に気に入っていますが、オブジェクトが少し複雑になるため、実装に苦労しています。すべてのフィールドを指定して、1 つの更新方法のみを使用するようユーザーに強制する必要があるのでしょうか?

例:

public Meeting
{
   public string Name {get; protected set;}        -- must have
   public DateTime Time {get; protected set;}      -- must have
   public IWine Wine {get; protected set;}         -- optional
   public string Notneeded2 {get; protected set;}  -- optional
   public string Notneeded3 {get; protected set;}  -- optional
   public string Notneeded4 {get; protected set;}  -- optional
   public string Notneeded5 {get; protected set;}  -- optional
   public string Notneeded6 {get; protected set;}  -- optional

   public IUser Chair {get; protected set;}         --must have 
   public List<IUsers> Users {get; protected set;}  --must have
   public bool isBoardRelated {get; protected set;}  --must have
   public List<IBoardUsers> {get; protected set;}   -- if isBoardRelated, then must have

   private void CheckInvariants()
   {
       if (blah == null &&....etc)
       {
             throw new ModelInvariantCheckException("Catch me and cry");
        }
    }

}

では、以下は、すべてのフィールドが指定された 1 つのコンストラクターと 1 つの更新メソッドのみをユーザーに提示する必要がありますか? それとも、複数のコンストラクターを使用する必要がありますか? 特定のプロパティ (オプション) をパブリック セッターに許可すると、一貫性が失われますか?

それとも、後で呼び出す必要がある isValid メソッドの使用を好むのでしょうか?

私の好みは、より安全に感じられるように不変チェックを行うことですが、すべてのプロパティをコンストラクターと更新メソッドの両方に追加する必要があるため、レイヤー間で呼び出すときや、オブジェクトのセットアップでさえ、処理が大幅に遅くなります。常に有効なクラスで構成されるコレクションは、これを悪化させます。

4

1 に答える 1

3

ドメイン駆動設計を実践するときは、大きな更新メソッドを避けたいと思うでしょう。更新メソッドは、ドメインの言語をキャプチャしません。データベース言語をドメインに取り込みます。言語を明示的にしようとすると、エンティティの状態を変更する値オブジェクト、不変条件、および意図を明らかにするメソッドを抽出できるようになります。

ここでインスピレーションを見つけることができるかもしれません。

于 2014-07-04T07:36:13.630 に答える