domain-classifier

ドメインロジック分類

コードやロジックがドメイン層に属するかアプリケーション層（ユースケース層）に属するかを判定する。

なぜ分類が重要か

ロジックの配置を誤ると以下の問題が生じる:

• ドメインロジックがユースケース層に漏れる → ロジックが重複し、不整合が発生する
• ユースケースロジックがドメイン層に混入する → ドメインモデルが技術的関心事で汚染される

判定ツリー

このロジックはどの層に属するか？
│
├─ ビジネスルール・不変条件を表現する
│  └→ ドメイン層
│
├─ 「〜であるべき」「〜してはならない」というルール
│  └→ ドメイン層
│
├─ 外部システムとの通信を含む
│  └→ インフラ層（アダプタ）
│
├─ 複数の集約を協調させる
│  └→ アプリケーション層（ユースケース）
│
├─ トランザクション管理を行う
│  └→ アプリケーション層
│
├─ 認証・認可の判定を行う
│  └→ アプリケーション層（※ドメインポリシーとして表現できる場合はドメイン層）
│
├─ 通知・ログ出力などの副作用を制御する
│  └→ アプリケーション層
│
├─ データの変換・マッピングを行う
│  └→ インフラ層（アダプタ）
│
└─ UIの表示ロジックを含む
   └→ プレゼンテーション層

各層の責務

ドメイン層

配置すべきもの:

• エンティティのビジネスルールと不変条件
• Value Objectの検証・計算ロジック
• ドメインサービス（複数エンティティにまたがるビジネスルール）
• ドメインイベントの定義
• リポジトリインターフェース（ポート）

リトマステスト: 「ドメインエキスパートに説明して、意味が通じるか？」通じればドメインロジックである。

アプリケーション層（ユースケース層）

配置すべきもの:

• ユースケースのオーケストレーション（手順の制御）
• トランザクション境界の管理
• ドメインオブジェクトの取得・保存の指示
• ドメインイベントのディスパッチ
• 外部サービス呼び出しの調整
• 認証・認可のチェック

リトマステスト: 「技術的な手順や調整を含むか？」含めばアプリケーション層である。

インフラストラクチャ層

配置すべきもの:

• リポジトリの実装
• 外部API・DBとの通信
• メッセージブローカーとの連携
• データのシリアライズ/デシリアライズ

具体的な判定例

ロジック	判定	理由
注文合計金額の計算	ドメイン	ビジネスルール
在庫が足りるか判定	ドメイン	ビジネス不変条件
注文確定→在庫引当→通知の手順	アプリケーション	オーケストレーション
メール送信	インフラ	外部システム通信
割引率の算出	ドメイン	ビジネスルール
ユーザーの権限チェック	アプリケーション	認可の制御
DBからの注文取得	インフラ	データアクセス
注文のキャンセル可否判定	ドメイン	ビジネスルール
CSV出力のフォーマット	インフラ	データ変換

グレーゾーンの判定指針

判断が難しいケースの指針:

ドメインサービス vs アプリケーションサービス:

• 外部依存がなく、純粋なビジネスルール → ドメインサービス
• 外部システムの呼び出しや調整を含む → アプリケーションサービス

ドメインイベント発行のタイミング:

• イベントの定義と発行条件 → ドメイン層
• イベントの購読とハンドリング → アプリケーション層

バリデーション:

• ビジネスルールとしての検証（「注文数は1以上」） → ドメイン層
• 入力形式の検証（「メールアドレスの形式」） → Value Object（ドメイン層）
• 存在チェック（「この商品IDは存在するか」） → アプリケーション層

コードベースの分類チェック

既存コードを分析する際は、以下の手順で進める:

1. 対象のクラス/メソッドを読む
2. 上記の判定ツリーに照らして分類する
3. 現在の配置が正しいか判定する
4. 誤配置がある場合、移動先と理由を提示する

擬似コード例

examples/ ディレクトリに具体例がある:

• examples/classification-examples.pseudo — ロジック分類の具体例