Clean Architecture is a follow-up post by Uncle Bob to much of the recent commentary on Clean Code Episode VII - Architecture, Use Cases, and High Level Design, including my own post called The delivery mechanism is an annoying detail. I'll keep this short because I only want to pick up on a couple of points. Uncle Bob says...
In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted.
I'm 100% behind the idea of keeping architectures clean and (as far as possible) decoupling the application code from the technology choices. I even mention "Boundary, Controller, Entity" in my The Frustrated Architect talk (video available) as a good way to decouple. I mean, why would you want to start a web server or database just to run some unit tests? That's crazy.
One somewhat dissenting view, written by The Frustrated Architect in his coding {the} architecture blog is here. He shows a picture, which I’ll repeat:
... see picture below ...
The point he’s trying to make is that if the UI and Database are a much larger part of the system than the business rules, then the architecture of the system should be more oriented around those larger elements. Of course I disagree. No matter how large any one part of the system is, the other parts should be decoupled from it.
No, that's not the point I'm trying to make. I'm saying the delivery mechanism is NOT an annoying detail that can be deferred or ignored "right off the end of the world". I'm going to quote myself here from The delivery mechanism is an annoying detail...
That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".
I consider the role of the software architect to be about looking after the big picture and the type of decoupling that Uncle Bob talks about is exactly the sort of architectural principle that I would adopt on my projects. However, in this role as a software architect, I'd be foolish to ignore the other major factors that may cause my project to fail. This includes, but is not limited to, all of the stuff that I quote above (tricky non-functional requirements, etc). A good software architecture is not just about clean code.
The executive summary
Again, to recap in case I'm not being clear...
- Decoupling application code from technology is good and certainly something we should all strive for. The result is code that is easy to unit test, easy to substitute, easy to maintain, easy to change, etc.
- Software architecture is about the big picture and application code is only one part of that big picture.
- You run the risk of your software project failing if you continually defer significant decisions about the "delivery mechanism" and don't consider how to address your significant non-functional requirements and/or constraints.
To summarise points 2 and 3 ... the delivery mechanism is not an annoying detail. Now, please go back and read Clean Architecture from the "Not Rocket Science" section because there's some really good advice in there. :-)