After understanding about the key concepts of Clean Architecture and some important concepts that surround it such as SOLID and component principles, it is easier to understand about its division into layers and its boundaries.
A system can be defined by three basic components: the UI, the business rules and the database - and in larger systems there are many more components. To explain the concept of layers and boundaries, the example made by MARTIN (2017) will be used, which describes the game of the 1970s called Hunt the Wumpus.
The rules of the game are irrelevant for this example, as the focus will be on the implementation itself.
Considering that a text-based UI is used, it is necessary to decouple the game rules so it can have different languages. The rules will communicate with the UI using an API, regardless of language, and the UI will translate to the requested language. In this way all UI components will be able to make use of the same rules of the game. Assuming that the game state is kept in a persistent store, there is no need for the game rules to know the details, so an API will be created to communicate these rules with the data store component.
The game rules must also not know about the different types of data storage, so the dependencies must be correctly addressed following the Dependency Rule, as seen in the game's basic structure figure (source: MARTIN (2017)).
After this brief description and based on Clean Architecture concepts, it is imagined that clean architecture would be easily applied in this example. However, not all architectural boundaries are clear.
In this example, the language is not the only UI change axis, the communication mechanism can also be varied, such as a chat application, a normal window or text messages. There are countless possibilities for change, which shows that there is an architectural limit defined by these axes of change. Therefore, it is necessary to create an API to cross this limit and isolate the language from the communication mechanism.
The figure above reflects the reformulated game structure (source: MARTIN (2017)), the dotted rectangles are the APIs and the rectangle written "Game Rules" contains the game rules. The Rules of the Game component is positioned at the top of the diagram, as it contains the highest level policies. This organization divides the data flow, being the left side to communicate with the user and the right side for data persistence. As systems grow, the component structure can be divided into several flows with different hierarchies, which makes the architecture increasingly complex.
MARTIN (2017) concludes this issue by stating that the role of the software architect is to assess costs, determine architectural limits and which of these limits should be fully implemented, which should be partially implemented and which should be ignored.
Conclusion
This simple example is meant to show that there are architectural boundaries everywhere, and it's up to software architects to recognize the needs.
It is also necessary to know that implementing these boundaries is something expensive, but at the same time, if not implemented early in development, they can have even greater costs over time.
Martin reinforces that these decisions are not made just once, that it is necessary to observe the evolution of the system, analyze where boundaries may be necessary and what can happen if they do not have well-defined boundaries. He also reinforces the importance of comparing the costs of implementing these boundaries with the cost of ignoring them, always looking to implement the right boundaries at the sweet spot where the cost of implementation is less than the cost of ignoring them.
References
- MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1st. ed. USA: Prentice Hall Press, 2017. ISBN 0134494164.
Top comments (0)