Uncle Bob and Simon Brown debate on the infrastructure’s role in drawing a system’s architecture.
In an earlier post entitled Screaming Architecture, Robert Martin (a.k.a. Uncle Bob) drove home the point that the architecture of a software product should make it obvious for everyone what purposes that product is supposed to serve, adding that the architecture of a system is supposed to reflect the use cases of that system and not the frameworks it uses:
Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.
Furthermore, a good architecture should allow one to defer almost indefinitely decisions related to frameworks, databases, web servers, etc., according to Uncle Bob:
A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat or MySql, until much later in the project. A good architecture makes it easy to change your mind about those decisions too. A good architecture emphasizes the use-cases and decouples them from peripheral concerns.
Uncle Bob goes on taking a look at the Internet and wondering if it should be considered a marginal concern, concluding that the web is also a “delivering mechanism”:
The Web is a delivery mechanism, and your application architecture should treat it as such. The fact that your application is delivered over the web is a detail and should not dominate your system structure. Indeed, the fact that your application is delivered over the web is something you should defer. Your system architecture should be as ignorant as possible about how it is to be delivered. You should be able to deliver it as a console app, or a web app, or a thick client app, or even a web service app, without undue complication or change to the fundamental architecture.
The conclusion of Uncle Bob’s post is that “Your architectures should tell readers about the system, not about the frameworks you used in your system.”
Simon Brown, a Software Architect, commented on Uncle Bob’s conception regarding the “delivery mechanism”, calling it “an annoying detail”. He agrees with Uncle Bob that the architecture of a system should not be about the frameworks used, but added that he would “like to see a software architecture grounded in reality, and that includes technology choices.” When it comes to deferring infrastructure decisions, Brown says: “Surely if there are some key technology choices that need to be made, then they should be made, right?”, then asks: “If I don't or can't defer decisions, does this mean that I have a bad architecture? Shouldn't deferral be a conscious decision rather than a rule?”
While Uncle Bob takes into consideration from an architectural point of view only the core domain of the system, Brown has a different approach considering that the “delivery mechanism” is quite a large chunk these days and should be integrated into the overall architecture, as shown in this picture:
Brown concludes:
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".
The debate did not stop there. Uncle Bob reacted to Brown’s position in another blog post, Clean Architecture, saying that no matter how large the UI and database sections are, the architecture of the system should not be oriented towards those “larger elements”, and “the other parts should be decoupled from it.” He goes on explaining that it is very important to decouple the core domain from the delivery mechanism, explaining that he does not artificially postpone and stop making any decisions on the frameworks involved, but that the architect should always keep a clear separation between the two parts even if they evolve simultaneously:
One of the more strident comments I’ve made about architecture is that a good architecture allows you to defer critical decisions like the UI, frameworks, database, etc. One point made by several people is that customers don’t want the UI deferred. DBAs don’t want the database deferred. From iteration to iteration they want to see the whole system working, including the UI, the Database, and the frameworks. They don’t want an iteration to be spent solely on business rules. Indeed, good agile practices specifically demand long skinny slices through the entire architecture.
Of course I agree with all of that. However long skinny slices don’t have to be coupled. A good architecture allows you to defer critical decisions, it doesn’t force you to defer them. However, if you can defer them, it means you have lots of flexibility. For example, you could create an interim simple UI for the first few sprints, and then replace it with a more capable UI later.
Uncle Bob concludes: “there’s nothing wrong with working on the annoying little details first, so long as you decouple your business rules from them.”
Brown responded in RE: Clean Architecture, agreeing with Uncle Bob on decoupling but he takes a different position on dealing with infrastructure concerns: “The delivery mechanism is NOT an annoying detail that can be deferred or ignored ‘right off the end of the world’”, as Uncle Bob affirms. Brown concludes:
- 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.
Uncle Bob and Brown are not really on opposing positions here. They both support a clear separation between the core domain and the supporting frameworks, but while the former focuses on the domain, the later considers that the infrastructure should be considered and taken into account. What is your approach?