ドメイン主導の設計プロジェクト構造
私は最近、ドメイン主導の設計と、概念的な用語で説明または説明されているほとんどの場所について読み始めました。設計哲学であるため、概念を理解するのに役立ちますが、DDDに従ってプロジェクトをどのように構成すればよいか疑問に思いました。
たとえば、ほとんどのプロジェクトで使用される一般的な構造では、次のようになります。
Root
- プレゼンテーション
- DAL
- サービス
- 図書館
- テスト
DDDでの同様のプロジェクトの構造はどのようになりますか？参照できるパブリックサンプルエンタープライズアプリケーションはありますか？
DDD（Blue Book）は、私が覚えている限り、プロジェクトの構造やパッケージの階層について明示的に言及していません。ただし、コードでユビキタス言語を使用する必要があります。
それをパッケージに変換することも理にかなっています。したがって、（例のように）技術用語に基づいてパッケージ化する代わりに、ビジネス用語（機能）に基づいてアプリケーションをパッケージ化できます。
これは、方法についての私の記事です 技術の代わりに機能に基づいたパッケージング 。
TL; DR：
- パッケージがサブパッケージに依存することはありません。
- サブパッケージは新しいコンセプトを導入するべきではなく、より詳細なものを導入するべきです。
- パッケージは、技術的な概念ではなく、ビジネス概念を反映する必要があります。
ドメインの内容によって異なります。
たとえば、ソースコードリポジトリドメインは、変更セットだけでなく、ファイル、フォルダ、パスにも関心があります。ここには他にも興味深いエンティティがあるかもしれませんが、すでにシステムが一緒になっているのを見ることができます。
特定のファイルシステムビューの周りに境界のあるコンテキストがあり、コミットを含む可能性のある変更セットの周りに別のコンテキストがあります。
ファイルシステムビューは、ドメイン内のセマンティクスがすべて同じであっても、いくつかの方法で提供できます。ブランチの特定のコミットでビューを変更します（変更セット、コミットなどの観点から実装されます）。また、ローカルチェックアウトのビュー（ホストosファイルシステムの抽象化に関して実装されます）。
これらのファイルシステムビューの実装はどちらも個別のライブラリ（または、相互依存関係のない同じライブラリ内の少なくともフォルダ）です。ファイルシステムビューのバインドされたコンテキストは、独自のディレクトリに存在する場合があります。
これは本質的にオニオンアーキテクチャのアイデアです。