本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。
本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。
Contents
AP層
要点
- AP層はサービスクラスなどと呼ばれるが、完全に合致するものではない様子。
- AP層(サービスクラス)は進行役であり、業務ロジック自体はかかない→ここに業務ロジックを書くとすぐに肥大化してしまうため。
- 業務ロジックはサービスクラスに書かずにドメインオブジェクトに任せる
- １つのドメインオブジェクトが複数のAP層から利用されているのが正しい使われ方である
- AP層(サービスクラス)、プレゼンテーション層、データベース層をそれぞれ独立させる
- 業務ロジックをAP層に集中させない
- 登録と参照のロジックを分離する
- リポジトリはデータベースとサービスクラスの橋渡し的な役割。基本的にこのリポジトリを利用して業務データの記録や参照などを行う。
- ただしリポジトリで行うものはデータベース操作ではなく、業務の関心ごととして記述するためのもの
- サービス層にデータベース操作の詳細を意識させない(隠す)工夫
- 画面の多様な要求は小さく分けて整理する
感想
いままでは業務ロジックのほとんどをいわゆるコントローラに書いてました。というかそういうものだと思ってました。基本的には(MVC+Util)みたいな感じで使っていたので・・・。ドメインオブジェクトを設計するとドメインにあたるもの(リポジトリ)に処理を任せることが多く、サービスはそれを呼び出して進める・・ということで解決できそう。こうすると複数の画面で似たような処理が起こってもドメインオブジェクトに処理を書いておけば共通化することができます。こういった設計思想の知識が全然なってないなー。
以下、用語の自分なりの解釈(ソースを触りながら多分修正することになりそうですが・・・)
用語
Service
コントローラとモデルの中間的な要素。実務でこういったクラスをみたことはあるのですが、自分の中でまだうまく言語化できていませんね・・・
Repository
データを直接データベースに格納するのに必要な処理をまとめたクラス。ただしINSERTやUPDATEといったSQLというよりは「業務レベルでの永続化の手続き」。これがあることでプレゼンテーション層とAP層はデータベースのことについて考えなくてすむ。いわゆる隠蔽できる。
Entity
テーブルをオブジェクト化したもの。
Value Object
テーブル以外の数量や金額などをオブジェクトかしたもの。いわゆるstringやintなどをラッピングしてこのクラスにしていると思われる。
上記の使い分けはむずい・・・あとはひたすらコードをみて(ただ書いて動かすだけではなく背景にある思想まで理解していないとダメ・・)
