Introduction
Architecture changes with the system but are independent of every other variable.
Software Design is Software Architecture, so every programmer is also a software architect.
The goal of architecture is to minimize the human resources required to build and maintain software systems.
The quality of the design can be measured by the effort that is required to meet customer needs. If the effort grows with time quality of the design is bad. If it is constant or shrinks design is good.
Slow and steady wins the race. The secret to going fast is to not build the roadblocks that will make You slow. The key to going fast is to go well.
Messes aren’t faster even in the short term. We’re expected to do a good job.
Disciplines feel slow but make You fast (TDD vs no discipline).
Values of software: Behavior and structure of software (ability to be changed).
It’s more important that software is changeable than that it works.
Requirements are urgent, but architecture is important.
Unimportant and not urgent probably won’t be done at all.
Unimportant and urgent are rarely done.
Important and Urgent will be done as a priority.
For important and not urgent (architecture) programmers need to fight over. If architecture comes last, the cost will grow.
Faulty architecture lies to stakeholders by making small changes expensive and big changes cheap. The solution is to have clean architecture so change costs predictably.
The programmer’s responsibility is to communicate the importance of architecture (structure of code). Remember that other people learn the truth by confrontation. It’s important for a programmer to learn to deal with people.
The programmers are stakeholders too because Your career depends on Your work. It’s gonna be a struggle.
Good architecture is about making decisions as late as possible. In that way, decisions are more informed. You need to decide about the language very early. But most of the other things can be decided later. Good architecture keeps options open.
Rules of Clean Architecture
The top-level application (architecture) should show the intent of the application, not the framework or IO.
Entities (Business objects) hold business or domain rules and are independent of the application. Entities are controlled by Use Cases.
Use Case (User Story, Interactors) consists of high levels: Data, Primary Path, Exception Path. It can be written as a Use Case class in a programming language. It contains application-specific business rules. Coordinate business rules.
Gateways (Input, Output Boundaries, Interfaces) are used by Use Cases to connect to IO devices and other external systems letting data in and out. The presenter reorganizes data into a View Model (change them to strings) to be presented. Repositories (Entity Gateway) implement the connection to databases to interact with them and make them abstract for business rules. Entities are not Objects created by ORM (object-relational mapper). ORMs belong to the implementation of Gateways.
External systems (Frameworks, Databases, Web, IO) it’s everything else that is not Your system. The external world should be separated from the system by Gateways.
Boundaries in clean architecture are very important. Here comes the Dependency rule: Across the architectural boundaries all dependencies point towards the business rules (Entities).
Thanks to the Dependency Rule business rules are resilient to changes in the rest of the system.
Data is passed by Data Transfer Objects not related to any framework. Request Model Object goes to Use Case, and Use Case produce Result Model Object.
Building systems this way testing everything is simpler and faster without access to the web or any other things like databases etc.
Mode View Controller was intended to work for small things like one button, input or canvas and it falls short as an architectural solution.
The database is a detail, just another IO device. SQL (text base language) shouldn’t be a solution. Instead, we should have a software API to access our data.
ESB (Enterprise Service Bus) and Frameworks are IO devices and the same rules apply to them in terms of architecture.
Frameworks encourage tight coupling to your system. They speed up at the very beginning but slow down in the long term. It’s a trade-off that architects should take into account. In the build/buy decision build is usually cheaper.
Dependency Injection should be used sparingly.
Sources:
Implementing the Clean Architecture (Sebastian Buczyński)
Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin)