Unityプロジェクトのディレクトリ構成について
目的
Unity Projectを扱う上のディレクトリ構成例について語ります。
いくつか例を示しますが、どれが正解などはないです。
共通の構成となる基本構成をまず記述します。
共通となる基本構成
とりあえず共通ライブラリ部分と、固有部分を分けています。
共通ライブラリは後々のプロジェクトでも使用することになるので、明確に分けています。
Assets
|_ <共通ライブラリ>
|_ <Project名>
|_ プロジェクト固有の好きな構成にする
構成例
構成例とはいえ、分け方でだいたい考えられるのは以下かなと思います。
- 「アーキテクチャの層で分けたにドメインで分ける」
- 「ドメインで分けた後にアーキテクチャごとに分ける」
- 「ドメインごとに分ける」
形になるかなと思います。
(これらをベースに、後はプロジェクト固有の構成に沿ってよしなに細部が分かれる)
では構成例について紹介します。
(紹介時にドメインに含まれる名前がないとわかりにくいので、Monsterというドメインがあるとします)
アーキテクチャの層で分けたにドメインで分ける
巷ではPresenterやModel,Viewなどいくつかの層に分けて運用することがあります。
この構成ではこの層ごとにまず分ける形になります。
Assets
|_ <Project名>
|_ Presenters
|_ Monsters
|_ Views
|_ Monsters
|_ Model
|_ Monsters
メリット
- 層が分かれているので、asmdefを切ることでチーム開発において、よからぬクラス間参照を防ぐ事ができる。
- 層がまず分かれているので、層直下でasmdefを切るだけですみ、シンプル。管理が楽。
- 層を軸にしてコードを探すタイプの人にとっては楽
デメリット
- ドメインを軸にしてコードを探すタイプの人にとっては手間
- 1ドメイン実装時に複数のフォルダを横断してファイル作成をする必要があり手間
ドメインで分けた後にアーキテクチャごとに分ける
先の例と逆のパターンです。
Assets
|_ <Project名>
|_Monsters
|_ Presenters
|_ Views
|_ Models
メリット
- ドメインを軸にコードを探すタイプの人にとっては楽
- 1ドメイン実装時に一つのフォルダ以下で操作を完結できる。
- 1フォルダ以下を見ることで、そのドメインが持つ機能を網羅できる。
デメリット
- よからぬクラス間参照を防ぎたい場合に各種層ごとにasmdefを切る必要があり、手間。管理が大変。
ドメインごとに分ける
もはや層ごとに分けることを放棄しています。
Assets
|_ <Project名>
|_Monsters
|_ HogePresenter.cs
|_ HogeView.cs
|_ HogeModel.cs
メリット
- ドメインを軸にコードを探すタイプの人にとっては楽
- 1ドメイン実装時に一つのフォルダ以下で操作を完結できる。
- 1フォルダ以下を見ることで、そのドメインが持つ機能を網羅できる。
- 先のasmdef管理から解放され、楽。
デメリット
- よからぬクラス間参照を防ぐ事ができない
終わりに
構成例は以上です。
自分は個人開発とチーム開発でそれぞれ分けています。
個人開発だとasmdef管理が面倒ですし、よからぬクラス間参照は行わないので 「ドメインごとに分ける」を採用しています。
チーム開発だとコードの品質管理が面倒になるので「アーキテクチャの層で分けたにドメインで分ける」を採用しています。