A year ago, the McHenry Cloud Developers ran out of services to look at, and transformed into Software Craftsmanship McHenry County. A surprise guest was “Uncle” Bob Martin, a legend of the field, who was quoted on the Software Craftsmanship Calendars that got handed out. For the one year anniversary, they asked Uncle Bob out to give a talk. It was one of those “We’re doing everything wrong” kind of moments.
I’ll be paraphrasing the talk from notes and memory – all errors are my own. You could also just watch the recording of Uncle Bob talking about Architecture
It started a long time ago – circa 1993 the world was ruled by C++ and COBOL, and object-oriented programming was born. The talk was built around a the book Object Oriented Software Engineering: A use case driven approach, which can be had (used) today for little more than the cost of shipping. There followed a period where people struggled to create proper object oriented architectures, using use cases (which today we know as user stories).
Then “all hell broke loose” – the web hit the scene, and time to market dominated everything else. It was circa 1995, Java and interpreted languages were on the rise and money was being throw at anyone doing software on the internet (today, it’s social media).
Then the tech bubble burst, and there were lots of young, jobless programmers asking what it meant to be a programmer – the birth of the agile movement.
Yet fast forward a few years and we see mostly frameworks. Ask somebody about their architecture and you’ll probably get something like “Struts and Hibernate on Tomcat” These are tools, not architecture. Web frameworks are often built on MVC, a GUI design pattern from circa 1978. In GUI MVC, a screen had dozens of views – each little widget.
When you talk about real architecture, you talk about things like floorplans, elevations, and utilities. The shape (especially the floorplan) should tell you what it’s for – it might scream office building for instance. This means it should scream at you about use cases. Most apps today scream at you about the web.
Use cases should be the central architectural guidance. They describe in a formal way how the user will interact with the system. They are described in terms of inputs and outputs. They are without trappings and delivery agnostic (e.g, don’t talk about forms, buttons, or pages) The use case might include a question and answer process. In the OOSE methodology, use case are represented by interactors (originally it was control objects, but Uncle Bob wanted to avoid any confusion with controllers).
Business objects become entities. They have the rules which are application agnostic and always true. All of these objects are “plain old xx objects”, which means they are easily and quickly unit testable.
Boundary objects connect the user interface to the interactors. They perform a kind of message passing using base data structures. It might involve presenters; basically a view gets data and renders it.
The database interface is in the interactors, because they manage transactions. (Aside: division into “DBAs” was invented by database companies for commercial reasons.) In any case, someone has to defend the schema, because it’s being pulled in different directions by every application. The schema is the lowest common denominator, it makes no sense to anyone because it has to serve everyone. The solution is database boundary layers which hide the schema and speak entities.
The point of this architecture is to defer critical decisions – such as desktop or GUI, which database, or even no database. A Ruby team fails if Rails is the first thing they do. (It’s kind of hard to defer the language decision.) The app should be thought of a kind of library (gem in Ruby) that is assembled with some IO system, such as the web.
During Q&A, Uncle Bob pointed to the Fitness testing framework as an example, although my brief investigation so far hasn’t been able to tease out the interactor/entity/boundary system he describes.
What now? We are doing everything wrong. (Or at least, I am.) I’ve had some leanings in this direction – the board game simulator was mostly an engine, with a little progress made on abstracting IO. Yet adopting this system is very daunting. Especially for existing projects where a major refactoring would be required. Even for new projects, you are weighing up front costs against the promise of future malleability. I might have to give Software Craftsmanship North America a try, even though it’s a tad pricey.
Update: Confreaks has released the Ruby-Midwest recording of Architechture: The Lost Years, complete with slides.