Clean Architecture
The clean architecture was defined by [[Robert Cecil Martin]] aka uncle Bob. The idea is to have a complete software architecture that is independent and have different layers, so your view layer does not know about the rest of the layers, and that's made possible to have a code where you can change the UI, for example [[Flutter]] for web and flutter for mobile apps. And the same goes for the other layers, your business logic does not know about the data and the presentation layer, making your core isolated of unnecessary changes.
See how dependencies always go to the centre, and how the core is fully protected from any external interference, allowing the development of implementation details to be fully contract-based, never exposing high-level details directly.
“If you think good architecture is expensive, try bad architecture.” [[Brian Foote]] and [[Joseph Yoder]]
In other words, provide a way for developers to organize their code in a way that the business rules are separeted from the delivery mechanisms[[Rodrigo Martins]]
The Clean Architecture is being used in the last years broadly, for different types of software, mobile, back end, front end … It has a lot of benefits, but like everything it has drawbacks, at the beginning can be quite challenging to think and actually make it work. More details to follow in this file.
As clean architecture is a modular architecture, it can provide a low manutenability if completed and well implemented[[Rodrigo Martins]]“Good software systems begin with clean code. On the one hand, if the bricks are not well made, the architecture of the building does’t matter much. On the other hand, you can make a substantial mess with well-made bricks. This is where the SOLID principles come in.”_ You can read more here. [[Robert Cecil Martin]]
Some of the benefits that clean architecture has:
- Testable: We can unit test our business rules more easily because they will be separated from any other layer of the system
- Independent of the UI: As we develop the architecture with abstraction, working with interfaces instead of concrete classes, this make possible to make changes like, which UI framework we're going to use, which database client, or external frameworks.
- Scalable: Following the concepts of solid, (o, open closed), we have a system that is open for extension and closed for changes, so this make our architecture scalable as we do not have a lot of objects with strong dependencies.
- Flexible: As our code starts to grow, at some point we will have deprecated API's or frameworks, and as we work with interfaces this facilitates replace the implementations or deprecate the old ones.
“Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.” [[Robert Cecil Martin]]
As a good architects we should consider several things before starting to code a new application, or even select which architecture to use, or frameworks, SDK's … And so on. Clean Architecture brings us a lot of rules that we must follow to have a complete separated layer of our application. So a concept that we need to take consideration is the [[YAGNI]], you need to solve the problem that you have right now, but think on what is going to happen in the future, and make some preparations for those changes. So do not overthink your architecture, [[refactor]] are going to happen all the time, and this is healthy for the application, there is no architecture or software perfect.
“Architectural refactoring is hard, and we’re still ignorant of its full costs, but it isn’t impossible.” [[Martin Fowler]]
And for this the teams needs a preparation a guide to work with it, you can not drive a car without knowing how to drive a car.
So the project must have an extensive documentation, where it explains to new developers how to work with that application, otherwise you're going to end up with complex pull requests reviews, bugs, and codes that may not follow the right pattern. As a team you need to define what are the limits of each layer, what are the common pattern the team should use to work, static annalists … Does not worth the time and effort to have an ideal architecture for the project if no one know how to work with it.
[[Robert Cecil Martin]] said software architecture knows how to draw clear boundaries of its classes and components to minimize the human resources required for its construction and maintenance. Your model has these limits very well-defined, each problem can have one or more appropriate solutions, the important thing when defining a software architecture is to be able to anticipate some decisions so that it is not too late.
The clan architecture can be defined also as a pyramid where, the top we have the code that is less suitable for changes and in the bottom we have the code that suffer more changes.
tags: #🛠 #software #dev #layers #domain #data #presenter #principles #considerations