domain-service

ドメインサービス設計

DDD におけるドメインサービスの設計と、ドメイン層内でのロジック配置（エンティティ / Value Object / ドメインサービス）の判断を支援する。

注: ドメイン層かアプリケーション層かの判定は domain-classifier スキルが担う。本スキルは「ドメイン層に属する」と判定されたロジックの、ドメイン層内での置き場所を扱う。

ドメインサービスとは

特定のエンティティや Value Object に自然に属さないドメインロジックを表現する、ステートレスなオブジェクトである。

特性:

• ステートレス: 状態を持たない。引数を受け取り結果を返すだけ
• ユビキタス言語の名前: ドメインの活動・操作を表す名前を持つ（例: TransferService、PricingPolicy）
• ドメインオブジェクトを扱う: 引数も戻り値もエンティティ・Value Object である
• 純粋なドメイン知識: トランザクション制御や外部システム呼び出しを含まない

最後の手段の原則

ドメインサービスは安易に作らない。まずエンティティ・Value Object に置けないかを必ず検討する。

このドメインロジックをどこに置くか？
│
├─ 1つのエンティティの状態とルールで完結する
│  └→ そのエンティティのメソッド
│
├─ 値の検証・計算・変換である
│  └→ Value Object のメソッド
│
├─ 1つの集約内で完結する
│  └→ 集約ルートのメソッド
│
├─ 複数の集約・エンティティにまたがり、
│  どれか1つに置くと不自然になる
│  └→ ドメインサービス
│
└─ ドメイン全体に適用される方針・ルールである
   └→ ドメインサービス（ポリシー）

リトマステスト: 「この操作の主語は誰か？」主語が特定のエンティティなら、そのエンティティのメソッドである。主語が見つからない（操作そのものが概念である）ならドメインサービスの候補である。

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

混同しやすいが責務が異なる。

観点	ドメインサービス	アプリケーションサービス
内容	ビジネスルールそのもの	ユースケースの手順制御
状態	ステートレス	ステートレス
依存	ドメインオブジェクトのみ（＋リポジトリインターフェース）	リポジトリ、外部サービス、トランザクション
例	送金額の妥当性判定、与信評価	「注文確定→在庫引当→通知」の調整
ドメインエキスパートに通じるか	通じる	技術的な手順を含む

判断に迷う場合は domain-classifier スキルの判定ツリーを使う。

典型的な適用ケース

1. 複数の集約にまたがる計算・判定

TransferService:
  transfer(from: Account, to: Account, amount: Money) -> TransferResult:
    assert from.canWithdraw(amount), "残高が不足している"
    from.withdraw(amount)
    to.deposit(amount)
    return TransferResult.success(from.id, to.id, amount)

送金は「どちらの口座のメソッドか」を決められない。操作そのものが概念である。

2. ドメインポリシー（方針の表現）

DiscountPolicy:
  applicableDiscount(customer: Customer, order: Order) -> Discount

割引方針は顧客にも注文にも属さない、独立したビジネスルールである。実装が複数ある場合はインターフェースとして定義し、差し替え可能にする。

3. リポジトリを参照する検証

一意性チェックなど、コレクション全体への問い合わせが必要なルール。

CustomerUniquenessChecker:
  // リポジトリのインターフェース（ポート）にのみ依存する
  isDuplicate(email: EmailAddress) -> boolean:
    return customerRepository.existsByEmail(email)

エンティティは自分以外のインスタンスを知らないため、エンティティには置けない。

4. 採番・生成ルール

業務的な採番ルール（年度プレフィックス付き連番等）は採番サービスとして明示する。

設計ガイドライン

• ステートレスに保つ: フィールドに状態を持たせない。設定値はコンストラクタ注入の不変値のみ許容する
• 命名はユビキタス言語から: 〜Service を機械的に付けず、PricingPolicy、UniquenessChecker のように責務を表す名前を検討する
• 引数・戻り値はドメインオブジェクト: プリミティブ型の羅列ではなく、エンティティ・Value Object を受け渡す
• 依存はドメイン層内に閉じる: リポジトリはインターフェース（ポート）のみ参照する。外部APIクライアントや ORM への依存はインフラの漏れである
• インターフェース化の基準: 実装が複数ある・差し替えたい場合のみインターフェースを切る。1実装なら具象クラスでよい

アンチパターン

アンチパターン	問題	対処
ロジックの吸い上げ	エンティティに置けるロジックをサービスに集め、貧血モデル化する	「最後の手段の原則」で配置を見直す
Manager / Helper / Util 命名	責務が不明確で何でも入る	ドメインの概念で命名し直し、責務を分割する
状態を持つサービス	ステートレス原則違反。並行性の問題を生む	状態はエンティティか引数に移す
手順の混入	トランザクション制御・通知などユースケースの手順を含む	アプリケーション層に移動する（domain-classifier 参照）
インフラへの直接依存	外部API・ORM をドメインサービスから呼ぶ	インターフェース（ポート）を定義しインフラ層に実装を置く
巨大サービス	1つのサービスに無関係なルールが同居する	概念ごとに分割する

既存コードの見直し手順

サービスクラスの肥大化を見直す際は、以下の手順で進める:

1. 対象サービスの各メソッドを列挙する
2. 各メソッドに「最後の手段の原則」の判断ツリーを適用する
3. エンティティ・Value Object に移動できるものを特定する
4. 残ったものをドメインサービス / アプリケーションサービスに分類する
5. 移動計画を提示する（テストで保護しながら段階的に移す。ddd-refactoring スキルを参照）

擬似コード例

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

• examples/domain-service-example.pseudo — 送金・ポリシー・一意性チェックの実装例