/note/tech

食べログが「Deal Provider」を構築した理由──「AIがなければ踏み出せなかった」DDDという20年前...

要約:

■ 1. 背景と課題

  • 食べログの販売管理システムは、飲食店のプラン契約・オプション管理・請求処理を一元管理するシステムである
  • 組織成長に伴い、販売管理チーム以外のチームが販売管理データを利用するシステムを開発するようになった
  • 結果として以下の課題が顕在化した:
    • ビジネスロジックの分散: オプション利用可否判定などが各システムで独自実装され、仕様変更時に複数箇所の修正が必要になった
    • データアクセス方法の非統一: 汎用API・個別API・ActiveRecordなど複数の取得手段が混在した
    • 判定ロジックの二重管理: 同一ロジックが複数システムで重複実装され、片方修正時に他方への影響が不明確になった
    • AIコーディング精度の低下: 責任所在が曖昧で参照すべきコードが散在していた

■ 2. Deal Providerの設計思想

  • 「データを渡す」から「判断済みの結果をサービスとして提供する」への設計転換を行った
  • DDD(ドメイン駆動設計)の原則「判断をドメインに閉じ込める」を実践する中間データ層として Deal Provider を構築した
  • 呼び出し元は複雑なロジックを意識せず、「そのオプションは有効ですか?」のように問い合わせるだけで判定結果を得られる

■ 3. 4層責務分離アーキテクチャ

  • Port層:
    • Adapterが満たすべきインターフェースを定義する
    • 実装詳細を上位層から隠蔽する役割を担う
  • Adapter層:
    • データ取得の具体的実装を担う
    • Portを include することで実装し、DB参照やAPI呼び出しなどを行う
    • データ取得元がDBからAPIへ変更されても、Adapterのみ差し替え可能な設計とした
  • Usecase層:
    • ビジネスプロセスを編成する
    • DomainServiceへのディスパッチャーとして機能する
  • DomainService層:
    • 複雑なビジネスロジックを集約する
    • 「この契約の販売事業者は誰か」といった判定を複数情報源から実施する

■ 4. AI活用の具体的方法

  • コンテキスト提供による精度向上:
    • ADR(Architecture Decision Records)と既存コードをAIに提供することで、設計の意図を理解した実装生成が可能になった
  • AIをルール番人として活用:
    • 従来はDDD原則の維持にチーム全員の継続的な学習と遵守が必要だったが、AIが実装段階で「この処理はどの層に書くべきか」を自動判定・強制できるようになった
  • ドキュメンテーション効率化:
    • AI時代においてAIのためにコンテキストを残す重要性が高まっており、ADRや議事録のAI生成も活用している

■ 5. 実装上の工夫

  • ADRによる意思決定の資産化:
    • 「なぜこの設計にしたのか」という背景を文書化することで、AIへのコンテキスト精度向上と新規メンバーの学習コスト削減を実現した
  • 厳格なコーディングルールの整備:
    • AdapterはPortを必ず経由する
    • Adapterから上位層への呼び出しを禁止する
    • Portの戻り値をActiveRecordの具象クラスに依存させない
    • RubyやActiveRecordの便利さをあえて制約することでロジック流出や依存逆転を防止した
  • 複数チーム間の責任明確化:
    • 販売管理チームが業務ロジックをDomainServiceに閉じ込め、利用チームはフラグを受け取るだけとすることで設計構造上の責任所在を自明にした

■ 6. 効果とまとめ

  • 課題解決の結果:
    • ロジック流出 → DomainServiceへの集約により修正箇所が1か所に集約された
    • データ取得方法の選択困難 → Deal Provider経由が明確なルールとして定まった
    • ロジックの二重管理 → 一元化によりシステム間の修正ズレが解消された
    • AIの文脈散在 → 新機能実装をAIに委譲可能になった
  • 開発効率の改善:
    • インバウンド向け店舗データAPI実装において体感30%ほど速く開発を進められた
    • 設計ルールがコードとドキュメントに組み込まれているため、AIへの指示が簡潔でも意図通りの実装が返される
  • 横展開の実績:
    • 「運営者変更判定」など別ドメインでもPort/Adapter + Usecase + DomainServiceパターンを適用でき、設計パターンの汎用性が立証された
  • 根本的なメッセージ:
    • 「正しいとわかっていても実践できなかった設計原則」を、AIが存在する今なら実践可能である
    • AIが「ルール番人」として機能することで、DDD導入の学習コストと品質維持コストが劇的に低下した
    • ドメインに責務を委ねたいが踏み出せない組織に対して、今がそのタイミングであるというメッセージを発信している