1. ドメインモデルの考え方で設計する
- ドメインモデルは業務ロジックをオブジェクト指向で整理する技法
- データの整理ではなく業務ロジックの整理
- 業務の関心事はヒト/モノ/コトで整理できる
- コトを整理の軸にする
- 起きてよいこと/起きてはいけなくことの判断と対応が業務ルール
- 業務ルールをオブジェクトで表現する一般的なパターンを覚えておくとドメインモデルの設計がやりやすくなる
- ドメインモデル設計のインプットは業務の言葉の正しい理解
- 業務の言葉を正しく覚え、正しく使えるようになることが、良いドメインモデルの設計に直結する
- 業務知識をプログラミング言語で体系的に表現したドメインモデルを中核にした業務アプリケーションは、変更が楽で安全になる
2. アプリケーション機能を組み立てる
サービスクラスに業務ロジックを書きたくなったら、それはドメイン モデルの改良の機会として積極的に活用しましょう。
サービスクラスは、プレゼンテーション層からの依頼を受け付ける窓 口です。
- いくらドメインモデルを充実させても、サービスクラスの設計は複雑になりがちです。その原因のひとつがサービスの依頼元のプレゼンテーション層です。
画面の多様な要求を小さく分けて整理する
三層+ドメインモデルの構造をわかりやすく実装する
プレゼンテーション層に影響される複雑さ
- 画面の多様な要求をサービスクラスの1つのメソッドに押し込めると、 そのメソッドはif文だらけになり、
小さく分ける
サービスクラスを小さく分ける基本は、まず登録系のサービスと参照系のサービスを分けてしまうことです。
意味のある最小単位で、かつ単独でテスト可能な単位にメソッドを分割するのがサービスクラス設計の基本です。
小さく分けたサービスを組み立てる
- プレゼンテーション層に業務の手順という業務知識が染み出 していることは問題
- 基本サービスを組み合わせた複合サービスを表現するために、別途、 シナリオクラスを作って、
- アプリケーション層のクラスを、プレゼンテーション層側のエラー処理の都合から独立させる方法として、例外は有力な選択肢 です。
利用する側と提供する側の合意を明確にする
- 例外を使うのは通常の使い方ではあまり起きない場合に限る
- どちらの場合も普通にあり得るのならIFで分岐させる
- サービスを利用する側と、サービスを提供する側とで、サービス提供の約束ごとを決め、設計をシンプルに保つ技法を契約による設計と呼びます
サービスを提供する側も利用する側も互いに何をしてくるかわからないという前提でさまざまな防御的なロジックを書くのが防御的プログラミングです。
契約による設計は、内部のデータ状態を外部から 隔離して隠ぺいする、オブジェクト指向設計の考え方の柱のひとつです。
- サービスクラスの設計にあたっては、プレゼンテーション層(使う側)と、どういう約束事でサービスを提供するかを決めるの設計が重要なテーマです。
基本的な約束事には次のものがあります。
・nullを渡さない/nullを返さない ・状態に依存する場合、使う側が事前に確認する ・約束を守ったうえでさらに異常が起きた場合、例外で通知する
