【ITニュース解説】Pragmatic Domain-Driven Design in Laravel, with Laravel Boost

このニュース記事は、人気のあるWebアプリケーションフレームワークであるLaravelを使いながら、Domain-Driven Design（DDD）という設計手法を効果的に導入するための具体的なアプローチについて解説している。特に、Laravel Boost DDDという新しいツールを使って、そのプロセスをスムーズに進める方法が提案されている。システムエンジニアを目指す上で、複雑なシステムをどのように整理し、開発していくかは非常に重要なテーマであり、この記事はその一つの実用的な解決策を示していると言えるだろう。

まず、Domain-Driven Design（DDD）とは何かを簡単に説明する。これは、ビジネスの複雑な問題をソフトウェアで解決する際に、そのビジネスの専門用語や概念をソフトウェアの設計に直接反映させることで、システムをより理解しやすく、変更に強くしようという考え方である。簡単に言えば、ビジネスの「ドメイン」（領域）を徹底的に理解し、それを中心にシステムを構築することを目指す。

通常、DDDを導入しようとすると、既存のフレームワークの機能を排除して、DDDの概念に合わせた独自のコード構造を強制されると感じることがある。しかし、この記事の筆者は、Laravelが提供する強力な機能（例えば、データベース操作を簡単にするEloquentモデル、認証・認可を管理するポリシー、イベント、キューなど）は非常に有用であり、これらを無理に置き換えるのではなく、DDDの考え方と共存させるべきだと主張する。DDDは、コードの「振る舞い」が「どこに属するべきか」を明確にするためのツールであり、Laravelのツールをすべて捨ててしまうことではないという考え方だ。

この考え方に基づいて開発されたのがLaravel Boost DDDである。Laravel Boostは、開発者がLaravelプロジェクトで作業する際に、コードの文脈（コンテキスト）を理解し、ガイドラインや特定のスキルを提供することで、コードの作成や変更を助けるツールだ。Laravel Boost DDDは、このBoostに対して、DDD構造に関するガイドラインや、特定の作業（例えば「Action」と呼ばれるユースケース処理のクラスを作成する方法や、ドメインルールをテストする方法など）を実行するためのスキルを追加する。さらに、導入したアーキテクチャが意図通りに機能しているかを自動的にチェックするためのテスト（アーキテクチャテスト）も提供される。

この記事で提案されている基本的なアプリケーション構造は、以下の3つの主要な層に分けられる。

• App\Domain\<Capability>：ここには、ビジネス上の最も重要なロジック（システムが解決すべきビジネス課題そのもの）や、「不変条件」と呼ばれる常に守られるべきビジネスルールが置かれる。例えば、注文の状態変更に関するルールなどがこれに該当する。
• App\Application\<Capability>：ここでは、「ユースケース」と呼ばれる具体的な利用シナリオ（例：注文のキャンセル、商品の追加など）や、それらのユースケースを実現するための処理の流れを調整（「オーケストレーション」）するコードが置かれる。
• App\Infrastructure：この層には、外部システムとの連携（データベース、外部API、ファイルシステムなど）や、各層が外部とやり取りするためのアダプター（変換役）が配置される。

これら3つの層に加えて、Laravelが通常使用するディレクトリ（コントローラー、コマンド、ジョブ、リスナー、ポリシー、プロバイダー、マイグレーション、ファクトリーなど）はそのまま活用される。ここで言う「Capability」（能力や機能）は、必ずしもDDDでいう「Bounded Context」（境界付けられたコンテキスト）という大規模な区切りを意味するわけではない。例えば、「注文」と「請求」が同じビジネスコンテキスト内の異なるCapabilityとして存在し、それらのモデルが直接連携することも許容される。

具体的な例として「注文のキャンセル」が挙げられている。まず、App\Domain層にあるOrderモデル（LaravelのEloquentモデル）が、「どの状態の注文ならキャンセルできるか」というビジネスルールを自身の中に持つ。例えば、「保留中の注文のみキャンセル可能」といったルールだ。 次に、App\Application層にある「Action」と呼ばれるクラスが、この注文キャンセルのユースケース全体を調整する役割を担う。具体的には、データベースから注文を読み込み、Laravelのポリシーを使って操作を行うユーザーがキャンセル権限を持っているかを確認し、Orderモデルのcancel()メソッドを呼び出して状態を変更し、その変更をデータベースに保存する。もし監査記録を書き込む必要があるなら、これらの処理を一連のデータベーストランザクションとして実行することも、このActionの責任範囲となる。 重要なのは、OrderモデルはLaravelのEloquentモデルのままであり、認証にはLaravelのポリシーが使われ、データベース操作にはLaravelの機能がそのまま使われる点だ。それぞれの「責任」が明確に分けられていることが重要で、モデルは自身の状態遷移の有効性を判断し、Actionはユースケース全体の流れを調整するという具合だ。

この記事では、DDDを導入する際にありがちな「過剰な抽象化」を避けることの重要性も強調している。DDDのパターン（リポジトリ、DTO、ドメインサービスなど）は有用だが、必要もないのにあらゆる場所に導入すると、かえってコードが複雑になり、理解しにくくなることがある。 このアプローチでは、デフォルトではLaravelのEloquentモデルを使って直接データベース操作を行う。例えば、単純な注文IDをわざわざ「データオブジェクト」（DTO）でラップする必要はない。認証済みの単純なデータ読み込みであれば、コントローラーに直接記述しても構わない。リポジトリパターンは、Eloquentだけでは対応できない複雑なデータベース操作が必要な場合にのみ導入することが推奨される。 「コントラクト」（インターフェース）も、実際のシステム間の「依存関係の境界」が必要な場合にのみ定義する。例えば、アプリケーションが決済ゲートウェイと連携する必要がある場合、Application層が「支払いを行う」という抽象的なコントラクトを定義し、Infrastructure層が特定の決済SDKを使った具体的な実装を提供する。これにより、アプリケーションのコアロジックは特定の決済サービスに依存せず、Laravelの依存性注入コンテナを使って柔軟に部品を接続できる。目標は、意味のある境界を持ちながらも、ユースケースが許す限り余計な仕組みを増やさないことだ。

また、Laravel Boost DDDの導入は「段階的に」行うことができる点も大きなメリットだ。このパッケージをインストールしても、既存のアプリケーションコードが自動的に移動することはない。新しい機能やCapabilityを開発する際に、このDDD構造に従ってコードを書き始め、既存のレガシーコードは必要に応じて少しずつ移行していくことができる。 これは、コードの境界線を導入することと、既存コードを整理・再構成することが別々のタスクであるという認識に基づいている。既存のコントローラーのバグを修正する際に、その機能全体を新しいネームスペースに移動させる必要はない。新しい機能を作る際に初めて、この構造を適用すれば良いのだ。 アーキテクチャテストも同様で、App\DomainやApp\Applicationといったディレクトリが存在する場合にのみ、それらのネームスペースのコードに対してチェックが適用される。まだこれらの層を採用していないアプリケーションでは、テストはスキップされる。これにより、既存のレガシーコードに影響を与えることなく、新しいコードから徐々に品質を向上させることが可能になる。

Laravel Boost DDDは、開発者がLaravelプロジェクトで作業する際に、これらのDDDの規約やガイドラインを受け取るための場を提供する。全体構造のガイドラインに加え、Actionの作成やドメインルールのテストといった具体的な作業のためのスキル、そして静的な制約（例えば、Domain層のコードがApplication層やInfrastructure層に依存してはならない、Actionクラスはhandle()メソッドを持つべき、など）をチェックするためのアーキテクチャテストを提供する。 ただし、アーキテクチャテストだけですべての品質を保証できるわけではない。例えば、認証が正しく機能しているか、データベーストランザクションが適切に適用されているか、イベントが正しいタイミングで発行されているかといった動的な振る舞いは、通常のユニットテストや統合テスト、そしてコードレビューを通じて確認する必要がある。

結論として、この記事はLaravelという強力なフレームワークを最大限に活用しつつ、DDDの設計思想を取り入れて、システムの責任範囲を明確にし、コードを理解しやすく、変更に強くするための実用的なアプローチを提案している。Laravelをアプリケーションフレームワークとして維持し、DDDの境界は責任を明確にするために必要な場合にのみ適用し、そしてその構造は段階的に導入するという、バランスの取れたアプローチを示していると言えるだろう。これは、システムエンジニアとして、大規模なプロジェクトや複雑なビジネスロジックを持つアプリケーション開発に取り組む上で、非常に参考になる考え方である。