目的
DDDはドメイン層がコアとなるので、オニオンアーキテクチャ等のドメイン層を中心に持つアーキテクチャがイメージしやすい。そして、このアーキテクチャを考慮したフォルダ構成を適用することで、このアーキテクチャを反映した実装も行いやすいと考えられる。そこで、この記事ではフォルダ構造を提案する。
フォルダ構造
┳ app ┳ presentation ━━┳ REST API
┃ ┃ ┗ SUB
┃ ┠ infrastructure ┳ repository(実装: domain.repository)
┃ ┃ ┗ PUB (実装: application.PUB)
┃ ┠ application ━━ ┳ usecase1
┃ ┃ ┠ usecase2
┃ ┃ ┗ PUB(インターフェース)
┃ ┗ domain ━━━━━━━━┳ models ┳ root-entity1 ┳ child-value-object1
┃ ┠ ┃ ┗ child-value-object2
┃ ┠ ┗ root-entity2 ┳ child-value-object1
┃ ┠ ┗ child-value-object2
┃ ┠ services
┃ ┠ factory
┃ ┗ repository(インターフェース)
┗ tests
考慮した内容
層をフォルダ単位で分ける
図に従って、presentation, infrastructure, application, domainでフォルダを分けた。層をフォルダ単位で分けることで、内側の層のロジック呼び出しが1つ外の層からだけ呼ばれていることを把握しやすくなる。また、それぞれの層の役割が考慮しやすくなる。
presentation層はコントローラー群
このサービスへのリクエストコントローラーを集めることで、どこからapplication層のロジックが呼ばれるか分かりやすくなる。
infrastructure層はアダプター群
外へのリクエストを行うアダプターを管理する場所で、application層やdomain層で用意したインターフェースの実装が集まる。
application層とdomain層を分ける
appilication層とdomain層を明確に分けることで、ドメインモデル貧血症を防ぎやすい
domain.serviceとdomain.modelを分ける
ドメイン層に含まれるモデルとサービスを分けることで、ドメインオブジェクトが持つべきルールと複数のドメインオブジェクトにまたがる処理の境界が明確になり、ドメインモデル貧血症を防ぎやすい
domain.modelをroot entity名で区切る
domain.modelは集約毎のルートエンティティを最上位のフォルダとして持ち、その中に集約内の子ドメインオブジェクトを入れていくことで、集約が把握しやすくなる。
testsフォルダはappの外
図内のTestsはユースケースが意図通りに実装できているかの確認のためのテストであり、これはappの外のフォルダに配置している