You could follow the previous posts here:
IV. Architecture
Before we go inside the Clean Architecture, we should answer that what is software architecture? and What does a software architect do?, and
when does he or she do it?
1. What is Architecture?
First of all, a software architect must be a programmer, and continues to be a
programmer. Vietnamese developers usually try to avoid coding and focus on higher level issues after several coding years. It's quite sad that the way of thinking has been creating a big gap between Vietnamese and US/Indian programmers. And in fact, there are not many quality programmers in Vietnam.
I could say that Software architects are the best programmers. And they continue to take programming tasks, while they also guide the rest of the team toward a design that
maximizes productivity.
The architecture of a software system is the shape of a system given by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.
All software systems can be decomposed into two major elements: policy and details
- The policy element embodies all the business rules and procedures. The policy is where the true value of the system lives.
- The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy, but that do not impact the behavior of the policy at all. They include IO devices, databases, web systems, servers, frameworks, communication protocols, and so forth.
Good architects design the policy so that decisions about the details can be delayed and deferred for as long as possible.
I mean a good architecture is one in which decisions about frameworks, databases, web servers, libraries,... are deferrable. A good architecture does not depend on those decisions.
And a Good Architecture must support
The use cases and operation of the system.
A shopping cart application with a good architecture will look like a
shopping cart application. The use cases of that system will be plainly visible
within the structure of that system. If the system must handle 100,000 customers per
second, the architecture must support that kind of throughput and response
time for each use case that demands it.
The maintenance of the system.
Recall that the goal of an architect is to minimize the human resources
required to build and maintain the required system
The development of the system.
Any organization that designs a system will produce a design whose structure is
a copy of the organization’s communication structure. A Good Architecture facilitates independent actions by those teams, so that the teams do not interfere with each other during development. This is accomplished by properly partitioning the system into well-isolated, independently developable components.
The deployment of the system.
The goal is “immediate deployment.” A good architecture does not rely on dozens of little configuration scripts and property file tweaks. A Good Architecture helps the system to be immediately deployable after build. And again, this is achieved through the proper partitioning and isolation of the components of the system.
2. Boundaries - Drawing lines
Software architecture is the art of drawing lines
You draw lines between things that matter and things that don’t. The GUI
doesn’t matter to the business rules, so there should be a line between them.
The database doesn’t matter to the GUI, so there should be a line between them. The database doesn’t matter to the business rules, so there should be a
line between them.
Specifically, you should put an interface between your design and data repository, which provides all the functionality we need to use when working with databases, but we do not implement those methods at first.
=> you can focus on getting the business rules written and tested before you have to make the database decision.
The same thing happens with the GUI. The core business rules should be kept separate from, and independent of, those components that are either optional or that can be implemented in many different forms.
Plugin architecture creates firewalls across which changes cannot propagate
To be honest, when you put those lines between components, you actually minimize the changes to propagate.
Arrange the code in those components such that the arrows between them point in one direction - toward the core business
Dependency arrows should be arranged to point from lower-level details to higher-level abstractions.
3. Screaming Architecture
If you are building a health care system, then when new programmers look at the source repository, their first impression should be, “Oh, this is a heath care system.”
- Software architectures are structures that support the use cases of the system and scream about them.
- If your architecture is based on frameworks, then it cannot be based on your use cases.
- Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments.
- If your system architecture is all about the use cases, you should be able to unit-test all those use cases without any of frameworks, databases, web servers
- Those new programmers should be able to learn all the use cases of the system, yet still not know how the system is delivered.
4. The Clean Architecture
After some parts to warm up, we will talk about the "Clean". You could see some of architectures such as Hexagon, BCE,... but they all have the same objective, which is the separation of concerns. So Uncle Bob give us some characteristics of a clean architecture:
- Divide the software into layers
- Independent of frameworks, UI, database, external services
- Testable without UI, database, web server, or any other external services
- The outer circles are mechanisms (details), the inner circles are policies (business rules)
- Source code dependencies must point only inward, toward higher-level policies
5. Details
as I said in previous parts, we must keep our business rules separate from those things:
Those things are significant, but they are details. You can use the framework - just don’t couple to it. Framework authors know their own problems, and the problems of their coworkers and friends. And they write their frameworks to solve those problems - not yours.
The architecture of the framework is often not very clean and tends to violate the Dependency Rule
When your product matures, it may outgrow the facilities of the framework. Or the framework may evolve in a direction that you don’t find helpful. You may be stuck upgrading to new versions that don’t help you. Or a new and better framework may come along that you wish you could switch to.
I could see coupling issues in my current company. Even by some experienced architects, framework/database coupling still exists.
So:
Keep the framework behind an architectural boundary for as long as possible
V. Conclusion
We went through 4 part of my notes about Clean Architecture. We could see some principles which are really precious in software development. Applying those principles will prevent you from some common traps which could pull you down to the hell.
Remember to separate your software into layers and use interfaces between them to decouple business rules and details. And your decisions of details should be delayed as long as possible so that you could have more information to choose them properly.
