目標
・ふわっとした理解のDDDについてエヴァンス本を通して体系的に学習する
・各章の要約をアウトプットすることで知識を定着させる
前回の記事
第1部の内容は以下でまとめています。
#1【勉強メモ】エヴァンス本からざっくり理解するDDD
#2【勉強メモ】エヴァンス本からざっくり理解するDDD
#3【勉強メモ】エヴァンス本からざっくり理解するDDD
【第2部】モデル駆動設計の構成要素
DDDを支える基本原則など
・責任駆動設計(responsibility-dreven design)
・契約による設計(design by contract)
第2部の3つの章の内容は「パターンランゲージ」として構成され
モデルのわずかな違いと設計における意思決定がDDDプロセスに
どれほどの影響を与えるかが示される。
【第4章】ドメインを隔離する
レイヤ化アーキテクチャ
・レイヤ化アーキテクチャ
ソフトウェアの関心事を分離しそれぞれの要素に集中できるようにする(凝集)アーキテクチャ。
レイヤ内のどの要素も、同じレイヤの他の要素か、その「下にある」レイヤの要素にしか依存することができない。
| レイヤ | 責務 |
|---|---|
| ユーザーインターフィエース層(UI) | ユーザーのコマンド解釈、情報表示 |
| アプリケーション層(AP) | ソフトウェアが行う仕事定義、ビジネスロジック |
| ドメイン層 | ビジネスの概要、状況、ルールを表すソフトウェアの核心 |
| インフラストラクチャ層(IF) | ドメインの永続化、DB接続等の技術的機能の提供 |
各レイヤの凝集度を高め上位レイヤに対しては疎結合にすることが
できてはじめてモデル駆動開発を実践することができる。
レイヤを関係づける
UI層をAP層やドメイン層と結びつけるパターン
・モデル・ビュー・コントローラ(MVCModel-View-Controller)
・モデル/ビュー分離パターン(Model-View Separation Pattern)
└モデル/ビュー分離パターン(Model-View Separation Pattern)
IF層はAP層の内容は背負わず、いつ実行するのかは知っているがどのように行うかまでは知らない状態にする。
ドメイン層はモデルが息づく場所
ドメイン層を隔離することは、ドメイン駆動設計の必須状況である。
モデルの概念を反映するドメイン層によって、ソフトウェアが構成される。
利口なUI「アンチパターン」
・利口なUI
ビジネスロジックをUI層に記述したり、AP層内の独立したUIとして実装することなど。
単純なアプリであれば生産性が高くすぐに動くものを作ることができるというメリットがある一方で、
アプリが成長しても複雑さによって機能追加やふるまいの豊かさを損ねてしまうというデメリットがある。
その他の隔離
他のドメインのコンポーネントと完全に結合しきれないモデルや、同じドメインに関する別のモデルを参照するケース
でモデルの有用性を損ねてしまうことに注意する。
まとめ
DDDで使われるアーキテクチャの概要やアンチパターンについて理解することができた。
次はソフトウェアで表現されたモデルについて学習する。
参考になったらいいねやコメントおまちしています！！