It seems to me that the topic of software architecture has attracted a lot of interest in the last few years. And among many different flavors and styles of software architecture, there’s one that attracts even more interest than the others.
It’s the Clean Architecture, Not a Clean Architecture
I’m talking about the clean architecture, proposed and evangelized by Robert C. Martin, a.k.a. Uncle Bob. (And for the rest of this post, it’s simply referred to as “clean architecture.”)
By employing clean architecture, you can design applications with very low coupling and independent of technical implementation details, such as databases and frameworks. That way, the application becomes easy to maintain and flexible to change. It also becomes intrinsically testable.
So here’s what we’re going to do in today’s post:
- We’ll start today’s post not by explaining what clean architecture is right away.
- We’ll then dive into the problems that high coupling can cause in software projects.
- Next, we’ll proceed to see the more mainstream solution to these problems.
- Finally, we’ll explain the flaws with this solution, showing why and how clean architecture can be the piece of the puzzle that was missing for your application to achieve its full potential.
Interested in seeing what your codebase’s current architecture looks like and whether it exists in the Zone of Pain?
Download the NDepend trial for free and see if your architecture is sustainable, let alone clean.
“Desperation” of Concerns
If you have at least a couple years of software development experience under your belt, then I can almost guarantee you’ve heard the term “separation of concerns.” It’s a principle that shows up quite often when talking about software architecture.
One of its incarnations is in the form of advice:
“Separate presentation from business logic.”
It’s very sound advice and I agree with it wholeheartedly, but the problem is that it’s not so easy or clear how to put it into practice, especially for beginners.
In practice, what ends up happening is that logic business frequently leaks to the application’s UI. And the same can go the other way around: it’s not so rare to find business logic code concerning itself with UI concepts, such as colors, markup languages, font sizes, and what have you.
And things can get even worse when you add data access to the mix. How does one free oneself from this mess?
Continue reading An Introduction to Clean Architecture