Clean Unity – Clean Architecture for Unity 3D

A Unity codebase does not have to be a bunch of “topic related classes”.
Your application handles user input, computing, network operations and must render a frame to be displayed to the user at each frame. You have to separate concerns.
That is, you should try to reduce as much as possible coupling between your view and your logic, and extract your networking operations in a separate bloc. Also always keep in mind that you should design your game module to be reusable as much as possible. You should avoid using the same data structure in different modules and thus you must introduce a way to provide data independence between related modules.

Some basic key concept of object oriented programming which sum up these ideas is the SOLID principle :

S : Single responsibility principle : each class is responsible of one and only one task (thus no UI should be displayed by your network interface class)


O : Open/closed principle : each module you develop must be Open for extension but closed for modification, that is the architecture should anticipate further changes and thus provide ways to add new related items in an easy way through inheritance for examples 

L : Liskov substitution principle : a subclass must preserve the purpose of its parent class, overrided methods or properties should have the same meaning as in parent class.

I : Interface segregation principle : Define interface by small unique roles, some class should be able to implement it and when doing so implement only methods useful to it.

D : Dependancy inversion principle : High-level modules should not depend on low-level modules, you must introduce some kind of abstraction through some interface. A great explanation can be found here : https://www.oodesign.com/dependency-inversion-principle.html

In order to help you today, I want to focus on how to apply Uncle Bob’s Clean Architecture to game development using Unity.

Let’s simply call it Clean Unity.

This architecture is a response to the need to keep your codebase clean, with single responsibility modules, testable and to organise your code with intents rather than a skeleton of your inner architecture choices.