レイヤ化アーキテクチャ
前回：ドメインを隔離する1
本質的な原則は、レイヤ内のどの要素も、同じレイヤの他の要素か、その「下にある」レイヤの要素にしか依存しない(第二部 第四章より)
それぞれ各層が、特定の側面を専門的に扱うことにより、凝集度が高まり、解釈がしやすくなる。しかも、各レイヤは別々の速度で進化するため、分離することで保守にかかるコストが下がります。
各レイヤの要素はそれぞれ以下の責務をもったものになります。
ユーザーインターフェイス(プレゼンテーション)
- ユーザーに情報を表示・ユーザーのコマンドを解釈
- 別のコンピュータへ情報を提示・別のコンピュータからのコマンドを解釈
- MVCアーキテクチャでいえばC
アプリケーション
- やるべき作業を調整 ○○して、△△して、xxする。実際の処理はドメイン層が行う
- 薄く保つ（メソッドは数行で済ませる)
- 状態はもたない
- ユーザーやプログラムが行う作業の進捗を反映する状態は持てる
書籍の銀行口座振り替えの例で言えば、
1. トランザクション開始して(実際の処理はインフラストラクチャが行う beginTransaction())
2. 口座振替を行う(実際の処理は口座モデルが行う transfer())
3. 確認(実際の処理は口座モデルが行う confirm())
4. 登録(実際の処理はインフラストラクチャが行う commit())
4行のメソッドになる
ドメイン(モデル)
- ビジネスの概念、情報、ビジネスルール
- ビジネスソフトウェアの核心
インフラストラクチャ
- 一般的な技術的機能
- メッセージ送信
- 永続化
- ウィジェット描画
特にモデルを分離することが大事なのは前回読んだ通りです。
意外と難しい
凝集度の高い側面を隔離するレイヤを選び出すことは
経験と慣習による何らかの収束が見られる。(第二部 第四章より)
自分もそうだったのですが、最初は特に、アプリケーション層にモデルに書くべきビジネスルールを書いてしまうことが多いです。
これは経験と慣れが必要ですね。
アプリケーション層を書くときにifやforを書いたときにちょっと立ち止まって、「これはモデルに書くべきか」と考える癖をつけるといいかもしれません。
ちょっと待った
モデルを隔離するということを何度も主張しているのですが、最初の図を見ていただくとわかると思います。実はモデルがインフラストラクチャ層の要素を持ってしまっています。完全に分離されていませんね。
モデルを完全に隔離することが大事なのですが、その工夫についてはまた後日。。。