レイヤリングとドメインモデル
Martin Fowler の bliki 3項目(Presentation Domain Data Layering、 Domain Driven Design、Bounded Context)を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
モジュール境界がどこで切るか、 結合の度合いが切れていないところの切れなさなら、 こちらは切った中をどう積むかと、境界ごとに言葉が変わること。
3つの層
情報を扱うプログラムでいちばん一般的な分け方。
| 層 | 中身 |
|---|---|
| プレゼンテーション | HTTP リクエストの処理、画面の描画 |
| ドメインロジック(業務ロジック) | 検証と計算 |
| データアクセス | データベースや遠隔サービスにある永続データ |
効く理由が3つ挙がっている。
注意の範囲を狭められる 集中している間は、1つの層だけを考えればよい
実装を差し替えられる 1つのドメインロジックを Web・モバイル・API・CLI で共有できる
永続化の技術を、業務ロジックに触らずに替えられる
テストの継ぎ目になる UI の複雑さや遅いデータベースなしに、ドメインロジックを試せる
3つ目はテストの 依存の扱いと同じことを、設計の側から言っている。
層を第一の分割軸にしない
ここが最も重要な指摘で、しかも実務で逆をやりがち。
どれかの層が大きくなったら、最上位を業務の領域に沿ったモジュールに分け、 その内側を層にする。
つまり大きな系では、プレゼンテーション / ドメイン / データを 最上位の境界にしてはいけない。
業務の能力で先に切り、層はその中に置く。
これはモジュール境界の 「業務の能力で切る」と完全に同じことを言っていて、 層で切るのは、その次の階層でやることという順序になる。
層でチームを分けない
組織の側にも同じ落とし穴がある。
フロントエンド班・バックエンド班・データベース班という分け方は、 摩擦を生み、利用者からの距離を作る。
開発者がフルスタックである必要はない。ただしチームはフルスタックであるべき。
モジュール境界の 分割の代償と同じ問題が、チームの切り方でも起きる。
層(layer)と階層(tier)は別
論理的な層であって、物理的な配置ではない。
1台の機械の上で全部動いてもよいし、複数のサーバーに分散してもよい。 層を分けたことが、そのままプロセスを分ける理由にはならない。
モノリスの判断とは独立している。
ドメインモデル
DDD の中心は、ドメインの過程と規則を豊かに理解したドメインモデルを プログラムすることにある。
Evans の貢献は、モデリングそのものではない。 ドメインモデリングは何十年も前からあった。転換したのは置き場所で、 紙の上でやるのをやめ、ソフトウェアの中でやり、 製品の生涯を通じて進化させ続けるようにしたこと。
主要な貢献として3つ挙がっている。
Evans の分類 エンティティ / 値オブジェクト / サービスオブジェクト
集約(Aggregate)
戦略的設計 境界づけられたコンテキストで大きな系を組み立てる
オブジェクト指向に限った話ではないとされている点は押さえておく。
ユビキタス言語
最も重要な貢献はこれ。
ドメインの用語を、そのままソフトウェアに埋め込む。
ドメインの専門家と開発者のあいだの溝を、 コードベース全体で語彙を共有することで埋める。
要求と見積りの 「要求の中身が実際に決まるのは会話の場」と対になっていて、 その会話で使った言葉が、そのままコードに入るという主張。
命名を設計の問題として扱う根拠にもなる。
境界づけられたコンテキスト
大きなモデルを完全に統一することは、実現可能でもなければ費用に見合いもしない。
理由は語彙にある。組織の中の集団ごとに、同じものを微妙に違う語彙で呼ぶ。 そして中心的な概念ほど、この混乱が激しくなる。
具体例が分かりやすい。電力会社では 「メーター」が3つの意味を持っていた。
系統と場所をつなぐ接続
系統と顧客をつなぐ接続
物理的な装置そのもの
Customer や Product も同じ多義語になる。
会話では曖昧なままやり過ごせるが、ソフトウェアの精度ではそれができない。
境目はどこか
モデルは開発者とドメイン専門家の意思疎通の道具なので、 言語が変わるところで、モデルも変わる。
つまり言語の境目が、そのままコンテキストの境目になる。
同じ概念を共有していても、モデルは全く違うことがある。
販売から見た Customer と、サポートから見た Customer は別物で、
サポートには問い合わせ票のような、販売側に存在しない概念もある。
コンテキストどうしをつなぐには、この多義性を対応づける仕組みが要る。 関係の型はいくつかあり、コンテキストマップとして図に表す。
このリポジトリでの位置づけ
| ここでの話 | 対応する場所 |
|---|---|
| 業務の能力で先に切る | モジュール境界 — 同じ結論に別の道筋で着く |
| 言語が変わるところが境目 | 同上。切り方の判断材料が1つ増える |
| コンテキスト間の対応づけ | 結合の度合い — 遠い要素の間は弱い連鎖にする |
| 統合の具体 | API 設計 |
| 語彙を共有する | 命名 / ドキュメント |
| 会話で決めた言葉を使う | 要求と見積り |
「業務の能力で切る」と「言語が変わるところで切る」は、 同じ場所を別の角度から見ている。 どちらか一方で決まらないときに、 もう一方が判断材料になる。