Part 2: Domain-Driven Directory Structures
– Organizing folders by Domain: Who Owns What in Your Unity Project
From code and configs to textures and meshes, every asset in your project should clearly belong to a domain. You should always be able to answer: Who owns this? and What project or system is it a part of?
Unity projects are rarely just one thing. You’re not just making a game, you’re pulling in plugins, building reusable systems, and layering tools. Your folder structure should reflect that reality without descending into chaos.
Let’s say you’ve just finished building a match-three game. You’ve even separated out all the logic into a standalone engine and it’s now a beautiful event-driven, pure C# library, not a monobehavior in sight.. nice! Now, you want to make a quick demo to show off your work and get others using it. Naturally, you reach for DOTween to do the swap animations and realise you’re not adding DOTween to your game, it’s not yours, you didn’t write it, but you’re adding it to your project. SO, where does it go?
The app or game project is owned by me or my company (or more likely, my client), so naturally it’s root folder lives under the name of the company that owns it, along with all the other assets I’ve created for them – These days my projects always start a structure like this: Assets/pixelfat/CandySmushSega/ <– This is the main game or application
Assets/pixelfat/MyMatch3Engine/
Besides the app sitting beside other projects it consumes, we can also use this pattern to promote common functionality to a generic /Unity folder as such:Assets/pixelfat/Unity/App/ <– For common app things like state machines or a Singleton base classAssets/pixelfat/Unity/Utilities/ <– My common utilities like generating random colors
Now, DOTween isn’t yours but you will be using it to demo your game, it’s a separate product, built and maintained by someone else, so we don’t mix it in with your own systems. Keep it in its own domain:
Assets/Demigiant/Assets/Demigiant/Dotween/
This structure makes ownership and boundaries crystal clear for you, your teammates, and for future-you coming back to this months later.
The /StreamingAssets Folder
Of course, being Unity, there are always some exceptions. Most notable is the StreamingAssets folder which has to be in the Assets folder. However, there’s no reason to treat that folder any differently, it’s simply a collection of all the binary assets you need for each project or feature, so we end up with something that’s once again, domain driven and traversable.
Nice and tidy!
The /Plugins Folder
“But Dan“, you say, “shouldn’t plugins be in a plugins folder?” – Well not necessarily. Unity treats the Plugins folder specially: it compiles scripts inside it earlier than the rest of your project and allows for platform-specific subfolders like /x86_64 or /Android. When we do, there’s no reason we can’t still follow our domain driven patterns, and Unity will accept multiple /Plugins folders so we have a few options. Whether it’s:Assets/Demigiant/Plugins/Dotween/
or this…Assets/Plugins/Demigiant/Dotween/
It really doesn’t matter, so why not continue using a domain driven pattern? Of course, you could always create a package, but that’s out of the scope of this series.
And what about when we don’t have an owner for our domain? Well, then we skip it and use the feature:
Assets/Plugins/SQLite/Android/arm64-v8a/libsqlite3.soAssets/Plugins/SQLite/Android/armeabi-v7a/libsqlite3.soAssets/Plugins/SQLite/Android/x86/libsqlite3.soAssets/Plugins/SQLite/x86/sqlite3.dllAssets/Plugins/SQLite/x64/sqlite3.dllAssets/Plugins/SQLite/Mono.Data.SqliteAssets/Plugins/SQLite/System.BuffersAssets/Plugins/SQLite/System.Memory
Coming soon.
With ownership and boundaries in place, we’ve laid the foundation. Next up, we’ll look at how to structure our actual code to take advantage of this system in Part 3: Structuring Projects with Namespaces & MVC.
Stay tuned!