ドメイン駆動を読む（第2部 DDDの応用 第4章 新しいデフォルトアーキテクチャ）

本

勉強会用のメモを兼ねています。

新しいデフォルトアーキテクチャ…DomainModelを基礎としたもの

  • データベース中心の設計からドメインモデル中心の設計に変わったのは、（主として効率性より）メンテナンスを重視するようになったから
    • より明快な設計になっており、実装がドメインの抽象に近いから長期的にみてメンテナンス性に優れている
    • テストのしやすさも増す

レイヤ分割

  • ドメインレイヤに注力。
  • コーディネートを担当するアプリケーションレイヤは、処理をドメインレイヤに委ねるだけの薄いもの（ServiceLayer参照）
    • POEAAのServiceLayerとDDDのServiceは言葉が似ているので注意。
    • アプリケーションレイヤはシナリオクラスみたいなもの
  • すべての呼び出しが下向きだとは限らない。インフラは永続記憶からインスタンスを再生成するときにドメインレイアの知識を持ち、インスタンスを作ってよい。（DDDのRepositoryのことかと思われ）

最初のスケッチ

  • 複雑で柔軟性に富むフィルタ…QueryObjectが一つの解決策。QueryObjectを使っていることはカプセル化しておくとよい
  • Repositoryを使ってカプセル化。クライアントはAPIを使いやすくなる
  • Repositoryはインスタンスのライフサイクルの面倒をみる
  • Repositoryメソッドに膨大な引数を取ることもできるが、「不吉な匂い」
    • stringのNameという引数があったとき、使い方がわからない。
      • 文字列が空のときは？その顧客を探す？名前はどうでもいい？
  • 双方向性はコストがかかる
    • Repository経由でたどり着くことにより、片方向の関連になる
  • 並行処理単位をつくるにはAggregateを使う。
    • パフォーマンス問題は、例えばLazyLoadを使って解決する
  • 最初からSPECIFICATIONに飛びつかなくてもよいのでは

ドメインモデルにUIを結びつける最初の試み

  • 目標：
  1. UIプログラマのために単純なAPIが提供てきているか
  2. UIプログラマはモデルを簡単に理解できてUIに集中できるか
  3. ドメインモデルとの間に複雑なプロトコルがあって気になるようなことはないか

さらに別の次元

ドメイン駆動 (Programmer’s SELECTION)

ドメイン駆動 (Programmer’s SELECTION)