プロジェクト構造の作成⚓︎
プロジェクト内のフォルダー構造⚓︎
各プロジェクトは、適切なフォルダー構造を作ってクラスファイルを整理します。 プロジェクト内のフォルダーは、原則として業務で分割してから層やコンポーネントの種類で分割するようにします。 配置するクラスの数が少ない ( おおよそ 30 以下 ) の場合、層やコンポーネントの種類でフォルダー分割することは推奨しません。 図のように、業務で分割したフォルダー内に、異なる種類のクラスをまとめて配置しましょう。
クラスの名前付けでクラスの役割を表現する
フォルダー内のクラスが、どの層のどのコンポーネントなのか、役割がわかりにくい場合は、クラス名の命名規則を設けて識別できるようにしましょう。 例えばクリーンアーキテクチャに従って作成した Application Core 層のプロジェクトの場合、エンティティ、値オブジェクト、アプリケーションサービス、ドメインサービス、リポジトリのインターフェースを同じフォルダー内に配置します。 エンティティや値オブジェクトのクラス名は、設計で抽出したキーワードをそのまま利用するようにします。 アプリケーションサービス、ドメインサービス、リポジトリのインターフェースは、各クラスの役割を表す語をクラス名の末尾に付けて識別します。
慣例として、コンポーネントの種類で先にフォルダー分割することもあります。 例えば Web API のコントローラークラスは、 Controllers フォルダーに配置することが多いです。 このような慣例がある場合は、そちらを優先してかまいません。
フォルダー構造と名前空間⚓︎
フォルダー構造は各クラスの名前空間と一致させるようにします。 このため、フォルダー構造をできる限り浅く保ち、名前空間の数をできる限り少なく保つ方が、コードがシンプルに保たれ、無駄な記述も少なくできます。
非機能要件を実現する機能の場合、フォルダー構造の検討は難しくなることがあります。 その場合は、 .NET SDK や ASP.NET Core に存在する似た機能を提供するクラスから、フォルダー構造や名前空間のヒントを探してみましょう。