When you set out to build a great new business application. You put some good ol’ white boarding to use, check the best tech stack for the job and start coding.
Everything is fine, until some years later when the application doesn’t feel so great anymore. Maybe the application has started to spiral out of control and performance has gotten worse or hard to manage. The tech stack you choose has aged poorly and receives few or no updates and needs to be updated but that requires a big refactor. And to top it off the new shiny technique that is much better has arrived.
In these scenarios it’s easy to see why it can end up as a legacy code. Because it would take too long to rewrite but it still produces value so it can’t be removed. If, when created the new application, you opted to write it in clean architecture you may have been in a much more favorable situation. What if it would be possible to rewrite it and only change a small part of the code and still keep the majority of the application?
Let me explain.
What is clean architecture?
Clean architecture is a way to structure your application. It’s all about layers. You will separate your code into layers (but are free to add layers depending on your needs). The most important thing is that you separate your inner layers (domain and application) from the outer layers (infrastructure and presentation). The inner layers will only use pure language functions, no (or very few) dependencies and no references from the inner to the outer layers.
The idea is that the inner layers should be as pure as possible but still contain all your domain and application logic. If something is dependent in the inner layers the whole application will depend on it, so the best is to have nothing to depend on. The further out you go in the layers the more implementation specific it will become and the more prone to changed it will be.
How to do the magic
If you have separated your application with inner and outer layers you will now be able to use the outer layers to define implementations. This can range from everything from what database to use, how to store and save files, APIs or other third party libraries. But, hey! I hear you say. Don’t I need to use the database in my inner layers? Yes, you will, but you will use it via interfaces. So the application layer will not know what database to use, it will only know how to use it. If we start with a database as SQL, NoSQL, memory address or in a text-file, the application layer would never know. As long as we only use the interface for the database and not the actual implementation.
Here we can start to see the power of clean architecture. With minimal effort we can replace the database implementation while still keeping all the business logic and entities in the inner layers intact. That’s great if it will ever will come a day when we want to change our database. But it doesn’t just work for databases. It works for everything.
Where to go from here?
It can be hard to grasp the implementation specific details of clean architecture, and to be sincere there’s no defined standard how to implement it. The best way is to keep to the principles. If you want to see a practical example I can recommend checking out Jason Taylor’s Northwind Traders or the newer repo with more basic examples, Clean Architecture. They are in C# but very implementation specific. And don’t forget to watch his presentation on clean architecture, it’s a must watch!
For me clean architecture was an eye-opener. I have long searched for a way to build applications in a good and structured way but it always felt that something was missing. Whatever I tried just turned out to be problematic in the long run, even if I followed best practices. The answer turned out to be clean architecture. If you can set it up correctly you can build applications with good structure that can last the test of time. It feels like I’ve found the way.