はじめに
こちらへ記載してあることは一個人の考え方・理解であり、間違っている箇所もあることを前提に見ていただけると幸いです。
アウトプットのつもりで、自分なりにまとめていこうと思います。
２部 モデル駆動設計の構成要素
2部でやることを章ごとにざっくりまとめる。
[モデル駆動設計]
4章
- ドメインを隔離するのに利用する
レイヤー化 アーキテクチャ - 排他的な選択
利口なUI
5章
- モデルを表現するのに利用する
サービス
エンティティ
値オブジェクト
6章
- カプセル化するのに使用
値オブジェクト→ファクトリ
エンティティ→ファクトリ
エンティティ→集約
集約→ファクトリ - 整合性を保ち、ルートとして機能する
エンティティ→集約 - アクセスするのに使用
エンティティ→リポジトリ
エンティティ→集約
集約→リポジトリ
それぞれの言葉の意味は章ごとに追々。。
4章 ドメインを隔離する
ドメインオブジェクトはシステムの他の機能から切り離して考える。
→ソフトウェアの技術にしか関係しない概念など。
レイヤー化アーキテクチャ
レイヤー化（階層化）することで設計が理解しやすくなる。
- それぞれのレイヤーはそれぞれの責務へ集中する
- レイヤーは同じレイヤーの同じ要素か、下層にあるレイヤーの要素にしか依存しない
ユーザーインターフェース層（プレゼンテーション層）
ユーザーに情報を表示して、ユーザーからインプットを受けつける。
アプリケーション層
ドメインオブジェクトが問題解決できるように調整する。
ビジネスルールや知識を含まない薄いレイヤー。
ドメイン層（モデル層）
ビジネスの概念・ビジネスの状況に関する情報やビジネスルールを表す。
この層がビジネスソフトウェアの核心である。
インフラストラクチャ層
上位のレイヤーを支える技術的機能を持つ。
ドメインのための永続化、アプリケーションのためのメッセージ送信、ユーザーインターフェースのための描画など。
レイヤー同士を関係付ける
レイヤー同士は疎結合にするべきで、上位のレイヤーからは下位のレイヤーを直接操作したり使用したりできる。→基本的な考え方。
※疎結合とは・・・システムの構成要素間の結びつきや互いの依存関係、関連性などが弱く、各々の独立性が高い状態。
インフラ層の技術的な機能はサービスとして提供されることが多い。
サービスを使うことで、上位レイヤーは「どうやって？」を気にしなくてよくなる。
例えば...
- メッセージをいつ送信するかは知っているが、「どうやって」アプリケーション層からメッセージを送るのか？
- 「どうやって」ドメインの状態をデータベースに保存する？
などを気にしなくてよいので本来の仕事だけに集中ができる。
ただ全ての技術的な機能をサービスとして作るのは大変...。
そういった場合に、アーキテクチャフレームワークが使われる。
<<使用する上での注意事項>>
- 制約が多いとドメインが設計しにくく、開発速度が落ちてしまう。
↓その為
フレームワークの最も価値のある機能だけを適用していくことで、実装とフレームワークを疎結合にしていく。
↓よって
設計上の意思決定をより柔軟にできるようになる。
利口なUI（アンチパターン）
「利口なUI」と「モデル駆動設計」は対抗するアプローチ
※利口なUIとは・・・画面に入れた情報がそのまま登録させるイメージ。
メリット
- 単純なアプリケーションで、スケジュールが短く期待値が低い
- それほど有能じゃない開発者だけでもできる
デメリット
- アプリケーションの統合が難しく、データベースを経由させるしかない
- ふるまいの再利用もビジネスの抽象化もできない
→同じような処理も複製して作ることに。 - サービスのふるまいを豊かにすることができない
- サービスの成長に限界がある
- オブジェクト指向プログラミングのメリットを活かせない
モデル駆動設計はこれらデメリットにアプローチできる。
利口なUIからモデル駆動設計の変更は、最初から作り直すことに。
まとめ
-
レイヤー化アーキテクチャはドメイン層が重要
ドメイン層を他のレイヤー層と分けて作るのが必須条件。
モデルとモデルに関係する設計が全て現れる場所である。 -
モデル駆動設計は、スキルも必要で大変だが大掛かりなプロジェクトに効果が高い。