アーキテクチャ
アーキテクチャの種類
DDD関連の文献でよく紹介されるアーキテクチャは下記３つです。
- レイヤードアーキテクチャ
- オニオンアーキテクチャ
- クリーンアーキテクチャ
構成要素や考え方が少し違いますが、本質的には全て同じです。
それぞれのアーキテクチャの共通点
1. 分離
すべてのアーキテクチャが、関心事の分離を重要視しています。
異なる責務を持つコードを明確に分離し、システムを構造化します。
これにより、各部分が独立して開発・テスト・変更可能になります。
2. モジュール性と疎結合
各コンポーネント（層やレイヤー）が疎結合で設計されるべきという考え方です。
特定のコンポーネントを変更しても、他の部分に影響が少ないようにします。
モジュールごとに独立した役割を持つことで、コードの再利用性や保守性が向上します。
3. 明確な依存関係の管理
依存関係は明確に定義し、制御することを重視します。
特に、依存関係の方向は、基本的に「高レベルのモジュール（ビジネスロジックなど）」が「低レベルのモジュール（データベースやUIなど）」に依存しないように設計されます。
4. テスト容易性
どのアーキテクチャも、ユニットテストや統合テストが容易になる設計を目指しています。
例えば、ビジネスロジックがインフラや外部システムから切り離されているため、モックやスタブを利用して独立してテスト可能です。
詳細
それぞれのアーキテクチャを詳しくみていきます。
レイヤードアーキテクチャ
プレゼンテーション層でクライアントとの入出力の管理、アプリケーション層でユースケースの実現、ドメイン層でドメイン知識の表現、インフラ層でDBとの入出力の管理を行います。このようにすると、レイヤーごとの凝集度が高まり、可読性や保守性を高めることができます。
しかし、このアーキテクチャには課題があります。
それはビジネスロジックがインフラ層に影響されるという点です。
DDDではドメインモデルを中心に設計を行いドメインの変更がしやすいようにすべきなのに、ドメイン層がインフラ層に依存してしまっています。
ドメイン層は容易に変更できるようにどこの層にも依存しないようにするべきです。
オニオンアーキテクチャ
レイヤードアーキテクチャから依存関係逆転の原則を用いてドメイン層とインフラ層の依存関係を逆転させたのがオニオンアーキテクチャです。
リポジトリはインターフェイスをドメイン層に、実装クラスをインフラ層に定義します。そうすると依存の方向性は実装クラスからインターフェイスになるので、レイヤーの依存も同様にインフラ層からドメイン層になります。
クリーンアーキテクチャ
層の分け方、名称や責務に細かい違いはありますが基本的にはオニオンアーキテクチャと近い形になっています。
オニオンアーキテクチャと比べると登場する要素が多いため、一般的な Web アプリケーションでは考慮不要なものも含まれており、適用する要素の選別に時間と労力がかかります。
DDDで採用すべきアーキテクチャ
DDDではオニオンアーキテクチャが採用されるケースが多いようです。
理由としては登場する要素がDDDの要素と一致していることと、複雑性が少ないことです。
オニオンアーキテクチャで実装を進めていく上で悩む点があればクリーンアーキテクチャから考え方を輸入してきたりして拡張していくのが良いのではないかと思います