Robert “Uncle Bob” Martin argues that an application’s purpose should determine its architecture; its delivery mechanism should not. If you look at an architectural drawing of a church, for example, you can tell it’s a church. But if you look at an architectural drawing of a web application, the fact that it’s a web application should not be the first thing you notice.
The web is a delivery mechanism. The web is a detail. The web is not particularly important to your application. … The web is a pipe. It is nothing more than a pipe. It is not the central abstraction of your application. It is not the grand, overarching thing that makes your application the application it is. The web is just a dumb detail. And yet it dominates our code.
From Robert Martin’s keynote at Ruby Midwest 2011. The quote starts about 9 minutes into the presentation.
He goes on to explain how to let the functionality of the application determine its architecture. In the dependency diagram arrows point from the delivery mechanism to the rest of the code, but none point the other way. By following this design you get something easier to test.
Well… Weather and climate are also just dumb incidental environmental details, but I would say a church design is at least as influenced by that (it has a roof, walls and windows; heating or cooling mechanisms; hurricane-proof roofs and so on as appropriate) as by its purpose as gathering spot for ritual.
On the other hand, the largest church in the US (or so I’m told) started life as a basketball arena.
I have a desktop app, web app, web service and daemon which all share large blocks of code, because they all need to have similar functionality. To do otherwise would be silly.
This is fine if the application is a stand alone application. But if it is interacting with other people, say a collaborative document editing website, or some kind of news aggregating website that takes ‘likes’ and +1s and combines them in real time to deliver trending news and similar, I’d say the web is an integral part of the application. It is still a pipe in a naive sense, but it would be like not worrying about the roads and other infrastructure while building a big port because it is ‘just roads’.
Uncle Bob is being a little facetious when he dismisses the distribution mechanism as a detail. He’s using hyperbole to shock a conference full of web developers into reconsidering how they work. Web-specific code should stay in its own box, even if that is a very big box.
This insight into the philosophy of code architecture is healthful, and well taken.
But, perversely, what caught my eye in this post was not the substance, but an unusually clear example of right and wrong punctuation.
You have used the word “it’s” four times in the first paragraph. The first two instances are wrong (should be “its”), while instances #3 and #4 are correct. Don’t be surprised if someone asks for permission to use that paragraph in an exam.
I think the analogies he presents are a great example of what i find is wrong with this presentation.
He can tell a building is a church by the arrangement of chairs. He can tell the building is a library because it has bookshelves.
He is not looking at the building, he is looking at the décor. That’s what’s easy to change! The real commitments are made made of concrete, not plywood.
And architecture is not just about deferring decisions, it’s about the commitments you have to make early on. If you do a storage agnostic model that works for in-memory data you might very well realize that there’s no database that can perform the operations you need fast enough for 10x the data.
Also, grand unified theories are hard. You have to do a web app. Take advantage of what you know. Make your life easier.
Put another way, specialization is easier than generalization. Its easier to specialize rails to meet your requirements than to abstract your requirements so they work everywhere.
Thanks. I’ve removed the embarrassing erroneous apostrophes.
I think it’s a good ideal to shoot for. I always prefer to code in language of the problem domain rather than the solution domain. Many disagree with this.
This is more difficult to do architecturally because we use frameworks that have their own “opinion” and we necessarily use solution patterns in the solution domain.
Short of specifying pure app logic declaratively and then generating the implementation for the web, or tablet, or rich client, we’ll always get some implementation on our problem and vice versa.
We’re all Reese’s developers. (with a nod to Hershey’s)
Dan,
Great point. But, isn’t implementation just translating from the problem domain to the solution domain?
Sometimes we have a great solution domain, and lets the code look like the solution domain, but i don’t think it ever really is.
Ouch, fix:
Sometimes we have a great solution domain, and lets the code look like its in the problem domain, but i don’t think it ever really is.
Lucio, yes, to an extent. I may have an app the does some interesting processing and presentation. Getting data from a database or from the user is not part of the core problem. It’s routine stuff commonly handled by a framework or library, but it may be a different framework/library for different platforms. dude.getPhoneNumber() may hide the database infrastructure and design but mapping URLs and building lists of elements is webby.
Some people like abstractions like GWT. Some like to work close to the web and in it’s terms. If I know it will always be web only, I’d rather work *with* the web and use something like Django. Unfortunately, I don’t believe in “always”.
We do build our own re-useable domain abstractions but we still reinvent the wheel way too often.
My in case TCP/IP is a pipe. HTML templates, CSS, and other code is my app. KISS.
For contrast I suggest to read:
http://en.wikipedia.org/wiki/Inner-platform_effect
http://thedailywtf.com/Articles/Soft_Coding.aspx
How about Resource Oriented Architecture?
The web as any ReSTafarian will say is more than a delivery mechanism. It’s a whole set of constraints, guidelines, best practices etc that (can/should) have a strong impact on the architecture of your web application. So I stopped reading after that…
Stelios
Stelios: REST came out of web development, but it doesn’t seem tied to web development to me. Seems more like a style of development. I don’t see why the REST approach to software development requires a web server or a browser.
I disagree. A church is built that way because a church is a mechanism for a pastor or other religious leader to talk to his flock. The delivery is through a speech, given by a guy speaking from the pulpit, somewhere toward the front of the church. The church’s accoustics (and size, and height) enable that purpose. The church’s organ music inspire the people inside spiritually to accept his message, as do the soaring arches (if any) or the steeple.
It’s ridiculous to say that the delivery mechanism is independent of the purpose of a message, or that an applications architecture is independent of its delivery mechanism. Delivery mechanisms provide tools to communicate. Of course the architecture of your application will be shaped by the strengths and limitations of the delivery mechanisms available.