【DDD】三層 + ドメインモデル

層	役割	説明
プレゼンテーション層	画面	進行役に処理を依頼します。
アプリケーション層	進行役	・処理の流れの進行役、調整役 ・「データソース層」と「ドメインモデル」を使います。
データソース層	記録と通知
ドメインモデル	業務ロジック

アプリケーション層

• プレゼンテーション層から依頼を受ける。
• 適切なドメインオブジェクトに判断、加工、計算を依頼する。
• プレゼンテーション層に結果を返す。
• データソース層に記録、通知の入出力を指示する。

フレームワーク

Spring Framework

開発者が業務ロジックに集中できるようにドメインモデル以外の三層の実装基盤を提供することを重視されて開発されたフレームワーク

サービスクラス

• プレゼンテーション層が要求するドメインオブジェクトを返したり登録するだけ
• サービスクラスに詳細な業務ロジックは記述しない。ドメインオブジェクトに任せる。
• if文で複雑になりそうな場合は、複数のメソッドに分ける。
• 機能追加で業務ロジックが増える場合は、ぎこちない形でもいいので、ドメインモデルにクラスを追加する。

サービスクラスを分けるコツ

大抵の業務システムでは、一つの画面でいろいろなことをしようとするのでサービスクラス自体も肥大化しがちになります。

サービスクラスを登録系と参照系に分けましょう。ただ、それでも一つの処理で、「登録」と「参照」をそれぞれ行う場合があったりします。その場合は、「組み合わせ用のサービスクラス」を別途作成するようにしましょう。

登録系

複雑です。適切な状態を管理するための事前事後の確認が必要になります。

不整合を発見した場合は例外処理を記述します。

参照系

あまり副作用がないので、安心して使えます。

シナリオクラス

基本的なサービスクラスを組み合わせた複合サービスを提供するクラス。

以下、２つのメリットがあります。

• アプリケーション機能の説明（業務手順書）
• シナリオテストの単位

ドメインモデル

• 複数のサービスクラスから参照されていてコードの重複がない状態が望ましい。

リポジトリ

ドメインオブジェクトの保管と取り出しができる格納場所。

全てのドメインオブジェクトをメモリ上に保管していつでも取り出せる仕組み。

サービスクラスからリポジトリを利用して業務データの記録、参照を行う。

データベース操作の詳細はサービスクラス層には意識させない。

例えば、注文情報を保存する際に、注文テーブルと、注文明細どちらにも記録するかもしれませんが、それは業務の関心ごとにはあまり関係ないためです。

メソッド名、引数、戻り値は全て業務の用語で表現する。