日々のディスカッション

打ち合わせの際に話をした内容をまとめる箇所

20090810

レイヤーアーキテクチャ

• Quickly(P24)の矢印はメソッドの呼出しを表している。
• DDDSample(下記URL参照)での細抜きの矢印は依存関係(使用関係)を表し、太抜きの矢印は依存関係(実装関係)を表している
• PofEAA(P17)では、レイヤー間は依存関係(使用関係)を表現しているが、DDD の場合には使用関係・実装関係の両方を表しているのが大きな違い。
• DDD(P68)の図の白抜き矢印はおかしい。恐らくこの図はUMLではない。
• UserInterface(以下 Interface)はUI周りのオブジェクトである。Interface の実装部が Infrastructure になっているのは、納得できる(例えばCustomTagLibとか)。
• Application はなくてもよい。複雑でないシステムでは、Interface から Domain を呼び出してもよい。Quickly(P24)でも Interface から Domain に矢印が引かれている。
• Application はユースケースと同じ単位とも考えられる。
• Domain は PofEAA の Domain Model(P116) と一致
• 例えば、メールを送信する、Domain のサービスがあった場合、どの権限のユーザを、To、Cc に振り分けるのは、Domain の役割。MailAPIを利用して送信を実行するのが Infrastructure の役割。
• Domain から Infrastructure の関連は二種類考えられる。ひとつは、上記メールのような呼出し元・先の関係。もうひとつはDDDSample の Repository の関係。CargoRepository の interface は Domain であるが、その実装である CargoRepositoryHibernate は Infrastructure である。
• FW に関連したオブジェクト・ORマッパーや、低層レイヤーAPIを用いたユーティリティも Infrastructure に該当するのでは。
• であれば、Interface から Infrastructure からの使用関係も納得。
• Infrastructure から Domain への使用関係が図では表現されていない。例えば、CargoRepositoryHibernate は Cargo と使用関係にある。
• Domain と Infrastructure が使用関係である場合、Domain と Infrastructure の依存関係をどこで区切るか(interface をどこで区切るか)ポイントになる。単体テストなどで影響が出る。
• Struts では... 【ここ覚えていないのでどなたか補足を...】
• Terasoluna では... 【ここも覚えていないのでどなたか補足を...】

エンティティ

• 一意性を持った Domain 上のオブジェクト。
• ここでいう一意性は、UserID などによりに一意性を表現しているものである。
• 一意性は PK のような項目でユニークな値を持ったオブジェクトだが、インスタンスレベルではユニークな値を持ったオブジェクトが複数存在するシステムが多い。(つまり、同一アクセスした場合、同じID値を持った別インスタンスが存在する場合があるという事。)
• Webシステムでは、リクエストを跨いだ場合に一意性を持ったエンティティのインスタンスを提供する仕組みを実現する必要がある？(こんな話してましたよね？)

バリューオブジェクト

• エンティティは一意性。バリューオブジェクトは一意性はないとするのが原則。
• Quickly(P30)図のエンティティとバリューオブジェクトの切り目をどのように検討するべきか？例えば申請書があったとする。申請書には、申請内容などの項目の他に住所を表す項目があったとする。その場合、申請書に対応するDBのテーブルは一つのテーブルに集約されるが、ドメインモデルでは(申請書と住所のように)幾つかのオブジェクトに分割される。
• もしこの場合、住所の一意性を求める事がユビキダス言語上に求められるのであれば、バリューオブジェクトからエンティティにすれば良いだけの事。
• バリューオブジェクトをいくら変更しても状態は変わらない(ようにする)。

サービス

• サービスは、どのドメインオブジェクトにも属さない(エンティティやバリューオブジェクトに含められない)振る舞いをサービスとして定義する。
• ここでいうサービスは、Application に属するサービスと、Domainに属するサービスがあるのでは。
• この点は DDDSampleで分けられているが、サンプル上ではあまり違いが見られない。

アグリゲート

• エンティティ(一意性オブジェクト)の一貫性を保持するオブジェクトの単位をアグリゲート
• アグリゲートはオブジェクトの関連の塊全体(とイメージしています)
• リポジトリやファクトリが返却するエンティティがアグリゲートのルートになる。そのエンティティは他のオブジェクトと関連がある状態で返却され、そのオブジェクトから関連があるすべてのオブジェクト群をアグリゲートとする？
• 例えば、伝票と明細の関係において、伝票：エンティティ、明細：バリューオブジェクトとする。リポジトリには、find というメソッドがあって引数に一意の伝票IDを渡すようになっている。伝票(アグリゲートのルート)から取得した明細オブジェクトをいくら操作しても伝票の状態変化(例えば合算値が変わるなど)しない。明細を追加する場合には、伝票(ルート)に操作を用意する。例えば、伝票に「add明細()」など。この中で、合算値を変更するような処理を書くとか。
• 参照と集約は別(って何を言ってましたっけ)