はじめに
DDD（ドメイン駆動開発）を学ぶにあたって避けては通れないレイヤードアーキティクチャの概略を簡単にまとめました。※初めてアーキテクチャを学ぶ初心者です。
3層アーキテクチャ（一般的なアーキテクチャ）
- プレゼンテーション層 = クライアントとの入出力をする層
- ビジネスロジック層 = ビジネスロジックの表現をする層
- データアクセス層 = データベースとの入出力をする層
問題点
ビジネスロジック層は、ロジックが複雑になりがちなため、設計がうまくできずにメンテナンス性が悪くなりやすい。
3層アーキテクチャの問題点を緩和するため、レイヤードアーキテクチャを採用すると、下記のようなレイヤーになる。
レイヤードアーキテクチャ
- UI層 = クライアントとの入出力をする層。Webフレームワークではコントローラに当たる部分。
- Application層 = ユースケースの実現をする層。
- Domain層 = ルールや制約などのドメイン知識の実現をする層。他の層にドメイン知識を流出しないようにする。
- Infrastructure層 = データベースとの出力をする層。ドメインの永続化を行うモジュールなど。
★ポイント：依存性の方向を意識して、各レイヤーに責務を分離する。
これにより肥大化していたビジネスロジック層が分離し、各層のロジックの凝集度があがることで、メンテナンス性が向上する。
メリット
- 影響箇所が明確。
ある層を変更した場合、影響を受けるのはその上の層のみなので
対応しなければならない箇所がわかりやすい。=>つまり、変化に強い。 - ドメイン層だけを見れば、データの整合性ルールがわかる。
デメリット
- チーム開発の場合は共通認識を作ることが大変。
- 通常よりもコストをかけて仕組みを作るので（コード量なども多くなる）、変化が少ない（メリットがあまり得られない）場合には不向き。
おわりに
DDDは特定の技術に依存していないため自由にアーキテクチャを選択することが可能。
ドメイン駆動設計と同時に語られることが多いアーキテクチャとして、レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャなどがある。