📚

CakePHP と DDD

に公開
CakePHP
アーキテクチャ
リファクタリング
ドメイン駆動設計
idea

CakePHP と DDD の相性について 🧩

はじめに

ある Web 申込システムが CakePHP で実装されてから 6 年以上経ち、今も開発が継続しています。
私は直近 1 年ほどその開発を担当しているのですが、システムの成長とともにいくつかの課題が見えてきました。

抱えていた問題

  • ドキュメントがほとんどなく、ビジネスロジックをソースコードから読み解く必要がある
  • スピード重視で開発されていたため、Controller に処理が直書きされている箇所が多く、理解に時間がかかる
  • DB 設計が甘く、1 テーブルに 40 カラム以上あるなど、スキーマが複雑化している

今後も開発が続く予定ですが、いまさら詳細なドキュメントを書くのは現実的ではありません。
そこで「ソースコードからビジネスロジックが自然と読み取れるようにする」ために、DDD の考え方を取り入れたリファクタリングを模索しています。

CakePHP と DDD の思想の違い

それぞれの強みを整理するとこんな感じです。

CakePHP (4.x)

  • MVC の中で共通利用できる Entity が便利
  • フレームワークとしての一貫性・生産性が高い

DDD

  • ドメインモデルを中心に据えるため、コードそのものが「業務の言語化」となる
  • ビジネスロジックをコード構造から読み取りやすくなる

課題感

特に大きいと感じたのは次の点です。

  • レイヤードアーキテクチャではレイヤー間の依存を弱めたいが、CakePHP の Entity は複数レイヤーで使われがち
    → その結果、インフラ寄りの都合がドメイン層にまで漏れやすい

模索したアプローチ

そこで現時点では、次のような方針で整理を進めています。

  • CakePHP の Entity はインフラ層に閉じ込める
  • View の処理もインフラ層にまとめる
  • ドメイン層以上は DDD の純度を保ち、フレームワーク依存を排除する

こうすることで、CakePHP の便利さを活かしつつ、ドメインの独立性を守れるのではないかと考えています。

おわりに

今回は CakePHP と DDD を組み合わせるにあたっての初期的な所感をまとめました。
今後はリファクタリングを進める中で「どこに線を引くべきか」「何をドメインに含めるか」など、具体的に悩んだポイントも記事にしていきたいと思います。

Discussion