はじめに
後輩から「調べたのですが、dddがよくわからなくて、、、」と相談を受けました。が、、、
「やばい、自分詳しく説明できない」
と思ったので、自分なりにわかりやすくまとめていこうと思います。
ドメインとは
ソフトウェア開発におけるドメインは、「プログラムを適用する対象となる領域」 を指します。
物流システムを例に出すと、トラックや、倉庫、輸送手段などがドメインに含まれます。またそれにあたる専門知識等 を指したりします。
ドメイン駆動設計とは
以下、Chatgptから引用
ドメイン駆動設計（Domain-Driven Design、略称：DDD）は、ソフトウェアの設計手法の一つであり、複雑なビジネスドメインを効果的にモデリングするための手法です。DDDは、ドメインの理解とモデリングを中心に据え、ビジネスドメインの要件を反映させた柔軟で保守性の高いソフトウェアを開発することを目指します。
以下、wikipediaから引用
ドメイン駆動設計（英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である[1][2]。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。
端的にまとめると、ドメイン（対象となるビジネス領域の知識等）を把握した上で、その知識を基にドメインモデルを構成し、そのモデルを動くソフトウェアに落とし込むことだと思います。
オニオンアーキテクチャとは
オニオンアーキテクチャは、ドメイン駆動設計（Domain-Driven Design, DDD）に基づいたソフトウェアアーキテクチャの一種です。オニオンアーキテクチャは、ソフトウェアの内部構造を円環状に分割し、ビジネスドメインのコアロジックを中心に配置することを特徴としています。
参考
前提
オニオンアーキテクチャを理解する上で、前提となる知識をあげます。
その他のアーキテクチャ
dddでは下記4つのアーキテクチャが主流になっています
- レイヤードアーキテクチャ
- ヘキサゴナルアーキテクチャ
- オニオンアーキテクチャ
- クリーンアーキテクチャ
オブジェクト指向
オニオンアーキテクチャは、オブジェクト指向を前提としたアーキテクチャです。
依存関係逆転の法則
オニオンアーキテクチャでは、依存関係逆転の法則が利用されています。(SOLIDの五原則の1つ)
依存関係逆転の法則とは、高レベルのモジュールが低レベルのモジュールに依存するのではなく、抽象化に依存すべきであるという考え方です。
- 高レベルモジュール（上位レベル）：注文処理モジュール
- 低レベルモジュール（下位レベル）：データベースアクセスモジュール
注文処理モジュールをデータベースアクセスでなく、抽象化に依存するのようにすることで、データベースへのアクセスの方法(使用するDBの変更等)の切り替えなどが容易になります。(つまりこういう情報があればいいよ〜と広義にすることで、アクセス方法等に依存しなくなる)
依存関係逆転の法則を適用することで、高レベルのモジュールは低レベルの詳細に依存せず、抽象化に依存することで、柔軟性と保守性を向上させることができます。
各層の役割
以下に図で出てきた、各層の役割について説明します。
ドメインモデル層
- ビジネスドメインのコアロジックやビジネスルールを表現する。
- ドメインモデルはエンティティ、バリューオブジェクトなどで構成され、ビジネスオブジェクトとその振る舞いを表現する。
E.g.ドメイン層
ドメインサービス層
- ドメインモデルが持つ責務の一部を凝集させている
- ドメインモデルに直接関連する操作や、複数のドメインオブジェクトにまたがる操作を提供
- ドメインサービスは、ビジネスルールやビジネスロジックの実装を含む場合があり、ドメインモデルの一部として表現されることもある
E.g. ドメインサービス層
アプリケーションサービス層
- アプリケーションの振る舞いを実装
- ユーザーインターフェースや外部APIとのやり取りを処理し、ビジネスロジックの組み立てやドメインモデルへの操作を行う
- アプリケーションサービスは、ドメインモデルの操作の組み合わせによってユースケースを実現する。
- トランザクションの管理やエラーハンドリングも担当
E.g. サービス層・アクション層・インターフェース層
インフラストラクチャ層
- データベース、キャッシング、外部サービス、ログ出力、メッセージングなど、外部要素とのやり取りを担当
- データの永続化や取得、外部サービスへのリクエストなど、ドメインモデルやアプリケーションサービスの要求を満たす役割
E.g.リポジトリ層
ドメイン駆動設計を用いることのメリット
1. ビジネスドメインの明確な理解
ビジネスのルールや概念をモデル化し、ドメインモデルを作成することで、開発者はビジネスドメインに対する理解を深めることができます。これにより、ソフトウェア開発とビジネスのコミュニケーションや協力がスムーズになります。(エンジニア以外の方でも理解できることを目指す設計方針でもあります)
2. 高い柔軟性と保守性
ドメインモデルを中心に各層の責務を明確化しているため、ソフトウェアの柔軟性が向上し、変更に対しても強くなります。また、ビジネスの要件の変更に対しても迅速に対応できるため、保守性が高くなります。
3. テスト容易性
ビジネスドメインのルールや振る舞いをモデル化するため、ユニットテストや統合テストの作成が容易です。ドメインモデルやドメインサービスは、ビジネスロジックを集約しているため、それらを単体テストすることで、ビジネスの要件を確実に満たしていることを検証できます。