Days of Domain-Driven Security

Dear Junior

It has been a truly interesting and challenging DDD Summit, where I have had the chance to present the subject of Domain-Driven Security and discuss it with several of the world's most prominent Domain-Driven Design experts.

There seems to be a general agreement that the way John Wilander, Erland Oftedal and I phrased the subject rings well with the insights of those experts, and that they agree on the means of using doman modelling and context mapping as tools to understand indata validation and vulnerability attacks as Cross-Site Scripting and the various forms of Injection.

I had the honor of being interviewed by Daniel Gackle on Domain-Driven Security as part of a series of DDD videos that Vladimir Gitlevich is producing, and I will surely let you know when it is online.

Daniel amongst others has also given me excellent feedback on my assorted ideas about Domain-Driven Security to give it some structure that is more easily accessible for someone that has not been deeply involved from the start. Hopefully there are some articles or other pieces of writing on their way. Not promising to much, but I will let you know.

You know well that one of my favorite phrases is "nothing is just a String" pointing out that a phone-number is more than any random string, that the same goes for a person's name, for an order number etc. This basically provides the case for typed value objects, typically with validation wrapped in the constructor.

John Wilander has brought this one step further. If it is questionable to ever have just a String, then should not String be an abstract class? Besides making an excellent point in a very well written blogpost, he also provides an example of injection besides the usual SQL Injection which often is easily dismissed as "a solved problem, use prepared statements". I really recommend reading his posting.

It seems to me like this particular week, Domain-Driven Security as a field is experiencing an unusual high level of activity.

Yours

   Dan

Ps. John Wilander recently defended his PhD thesis on software security. Whereas the full text is of course pretty long, he also included a "popular brief" in Swedish which in a few pages summarises his work. Well worth reading, and a good example I think more researchers should follow.

Domain Driven Design to Speed us Up by Opening Options

Dear Junior

At the DDD Summit a year ago there was an interesting discussion about how we motivate doing Domain Driven Design. We noted that one of the classical argument have been "proper domain modelling will make maintenance and further development easier", an argument which I have used myself. 

However, this is really a bogus argument; it more or less boils down to saying "spending a lot of time now will save us time later", which is a non-argument for anyone buying into the agile view of creating software. We need a better argument - If we are doing DDD it should be because it saves us time now.

The general agreement last year was that domain modelling actually do speed us up now, so doing domain modelling saves time in the short term, e g the stories at hand in the current sprint if you are doing scrum. However, we did not much discuss the mechanisms that make it so.

I have had this discussion in the back of my head during the last year, trying to keep my eyes open for how this could be the case - how doing more work actually could result in less work.

At the DDD Summit this year I had a really rewarding discussion about this with Steve Bohlen, sharing our experiences from the passed year. 

If you do not do domain modelling, you will look at the story to implement from a technical perspective. Doing so there is probably an "obvious" way to do it - "run that job, select the data from the database with a new where-clause, fetch it via XyzService, and push it to presentation". The approach will include activities A, B, C, D, and E - so write down those as five tasks, post them as stickies on the sprint board and start working. How could extra domain modelling save us time? Will it really make us work faster?

In order to make sense, let us think about "saving time" in the opposite direction. Efficiency can be seen as working fast. However, it can also be view as "maximising the work not done", which is how it is phrased in the Agile Manifesto as the principle of simplicity.

One of the important mechanisms of domain modelling (if done right) is that it opens up options. In a domain modelling session you challenge yourself and the team to think about the problem in different ways, and a good modelling session might well result in three different ways of thinking about the problem - and thus generating three different solution. 

Evaluating three different solutions might give you that first include activity A, C, E, and F. Second include B, F, and G. Third include A, B, D, F, H, and I. Now of these some might be worse than the "technically obvious solution". In this case third solution is probably worse; six activities instead of five. 

Finding solutions that are worse than the one you had (the "technical")? Surely that must be a true waste of time!

However, you do not only find solutions worse, you most probably find some that is better. And, you only have to implement one of them - the best one. In this case, the simplest solution is the second, only requiring three activities. 

It is a little bit like throwing dice trying to throw an as low number as possible. Throwing one die will give 1 to 6 equal probability, so your average low will be 3.5. If you throw two dice, each die will give 1 to 6 equal. However, for 6 to be the minimum you will have to throw [6, 6] which is 1 chance out of 36. For five to be minimum you have to throw [5, 5], [5, 6], or [6, 5] - 3 out of 36. For three it will be 7 out of 36. For one it is 13/36. Throwing one extra die heavily skews the odds for throwing a lower throw ("finding a simpler solution").

Back to software creation, the simplest solution found during the domain modelling is most probably easier that the solution that was obvious from the technical perspective. A small investment in opening options was well outweighed by finding a easier solution. So, we save time not by working faster, but by working smarter.

And just to be clear - we are talking about a small investment in domain modelling, like a few hours or a day. It is not about a "phase of the project" were you spend weeks in day-in-day-out workshops and discussions.

During the year my colleague Daniel Deogun had a wonderful example of this happening at our common client. At the sprint planning the team was convinced that they knew how to implement the story at hand. However, just to open up options, Daniel kidnapped the team for a two-hour domain modelling session. During that time they found new ways of looking at what they were building. So they ended up not touching the code they had envisioned to change. Instead they changed somewhere completely different and the amount of work shrank from being a dominating part of a sprint to be a few half-days of work for a few team members. And that insight was driven by asking questions about the domain - trying to phrase the answer in different ways.

So, doing more work to save time might seem very unintuitive. However thinking about it as finding options to "maximise work not done", I think it makes sense. In a way, what we are avoiding is the sadness of a really fast boat sailing at high speed in the wrong direction.

Yours

   Dan

PS BTW, Steve and I had more interesting discussion around this topic, but that will need to be the topic of another letter.

PSS Using the metaphor of orienteering what DDD modelling do is to spend a while to study the map, exploring different routes. As an orienteering runner this is definitely a smart move to make us faster.