Clean Architecture Design – the weakness of “Defer Decision”

In this video (http://www.youtube.com/watch?v=asLUTiJJqdE) “Uncle Bob” (Robert C. Martin) talks about clean architecture. While I agree with many of his statements completely (mainly because from my experience I can tell you: many things simply are true – no matter whether you believe in them or not), there are some things I really do not agree with. One of them is “Defer Decision of Database and Data Model”. But wait a moment before you tell scream “But deferring decisions is what’s that whole talk is about!” – Because I think: it’s not.

The key point is not to decide late on one technology or another – you can build a very clean architecture even if you already have some technology decisions done. You can build a clean architecture in a project environment where MS-SQL is mandatory for business data storage, where you only have .NET developers with web experience and IE is the only browser allowed on the client PCs. The key is not to not already have that decisions – the key is to not let them dominate your mind while architecting the system.

Another issue I see with his approach (building the Business User Cases upfront) is that you need to decide e.g. the maximum length of a name, street etc. in order to be able to store it somewhere in a structured way. If you start designing use cases, you might analyze the sample data of that use cases and design your system using that data. For simplicity I will assume something really stupid outside the software development world: I will analyze the specification of a “house”. The specification says: “we need some doors”. Well, that’s ok, but what size of doors? Well, we will “unit-test” the door by letting all the project members go through that door and we see that 90 % of them will match with a door height of 1.80 m. Well, that’s nice, isn’t it? We can buy 20 of those 1.80 m doors and put them into the building, since we know the people that will use this house and we even did a better job than the 80/20-rule that states the last 20% of your goal might cost you 80% of the price, so 80% match might be “good enough” (test went green).

Obviously we did the wrong decision – and it will be very costly to fix that, because we might also did the wrong decision about the room height. So what went wrong in this stupid example? Simply that: we did concentrate of a specific small group of test cases that are part of our “current use cases” and we didn’t expect the test data to be incomplete, because it did match the use cases. How could we have prevented that issue? Multiple ways:

Ask someone with experience – well in software design, this might be an issue, because if there is already a system that does the same thing as your planned software (only in that case there is someone with the experience), why are you designing a new system? If that existing software does not fit, the experience of the person who built it might not be such a good guidance.

Wait for the decision what door to order as long as you can … well sometimes that’s not an option: to size the height of the rooms correctly, you will need to make assumptions early. You might defer the decision about the door, but then this decision will be done implicitly – without careful considerations. You might hope that this implicit decision (door height < room height) is a good one … but: “Hope is not a management tool!”

Look for better test data – that’s the way I would prefer, but the problem in this case is “What is better test data? And how do we ensure that this new test data would not be restricted to the current use cases as the data before?”

To create really good data models they don’t need to include each and every aspect you might need in the future – there is a very simple rule to follow that will allow you to design systems that last a huge amount of time with very little redesign: “Do not design things that are not true!”. If you have such a decision about the height of a door, ask everyone in the team: what would make our assumption “people need a max. height of a door of 1.80 m” wrong? The will tell you that there might be even taller people in other projects – then you should consider sticking to a standard (and for nearly everything there is a standard) or start research about people height.

But back to the database decision – how would the early decision of a database and its structure help you? Wouldn’t it hurt? Well it will not hurt if you already have such a decision in place (most enterprises do have policies about that) – and the chance is really low (if not equal to zero) that you will have to change that database system if you are writing in-house software. Will it give you an advantage? Yes: it will allow you to start modelling and store information in a persistent way, that will last for more than one iteration and it will force you (and your customer) to start re-thinking your model. And that’s what it’s really all about: think carefully about your model decisions – do not model anything that’s not 100% real. If thinking about the model takes more time, delaying decisions makes sense – but deferring decisions by its own does not add any value to the architecture … you can make bad decisions any time if they do not match reality.

Advertisements

Share this:

Like this:

LikeLoading...

This entry was posted on Wednesday, February 27th, 2013 at 8:28 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

Post navigation

Full Ack. I do think that defering decisions actually is good advice. But certainly not to the point that defering the decission starts to hurt by itself.
That’s a concern I have with many of Uncle Bobs Statements: Briliant at their core, but taken to extremes.