Domain Driven Design by Eric Evans - my book review

To me this book has been a huge disappointment. Someone told me "Pete, there's a name for what you do!" and pointed me to this book.

Now personally I prefer technical books, as I read the Ubiquitous Language part at the start I thought to myself "Not technical, but fair enough some people will get value from being taught how to ask questions" and I stuck with it.

The first thing I must say that I cannot stand and which happens a lot in this book is over emphasis. When you want to emphasise something it needs to stand out. This book not only emphasises whole paragraphs but does it far too often too. Being an Internet user for some time now when I read upper case letters the imagined vocalisation actually SHOUTS at me, when I read bold my brain vocalises it as a loud and punctuated word, so when I read a whole paragraph in bold I, READ, EACH, WORD, LIKE, THIS; it makes it difficult to read.

Another thing I don't like when reading something is reading it for the Nth time. I don't mind a bit of reiteration in the way of reading something and then at the end telling me it is another example of "X" but only if the example is so different that it probably didn't occur to me. When I am on page 400+ I really don't want to be reading more examples of what I was reading in the first chapter. It really switches my brain off when so far into the book I am reading yet another example of "The Ubiquitous Language" that was covered at the start of the book. To be honest I am finding it very difficult to motivate myself to read the remainder of the book.

So, what have I learned from the book? I would say I have learned 1 valuable thing. Many times in the past I have modeled a parent/child association such as PurchaseOrder, and then modeled a kin-like parent/child such as Invoice/InvoiceLine, where the invoice is always for a single order and each invoice line is for a specific order line. In these circumstances I would have both Invoice.Order and InvoiceLine.OrderLine, everytime I did this I would cringe, it just felt "wrong" or "messy". Enforcing the idea that I should have no direct associations to the aggregated parts of the Order means that now I merely have Invoice.Order, it's easy to see which order line the invoice line is for because they are ordered the same and both the order and invoice are immutible. Now, I don't agree with the idea of never referencing an aggregated part, but at least now I consider the option. It certainly cleaned up a 3 kin-like aggregate part of the model I am currently working on.

For someone who doesn't know how to talk the "language of the current domain" with a customer I can see that this book could be useful, and also for people who need some pointers on how to segment their apps a bit.

When I read about people mentioning the "map of the world" example being such an eye opener (or whatever other way they express their positive experience) it honestly amazes me. The idea that a "Customer" to company A is completely different from how company B sees one as a break through just makes me shake my head in disbelief. In some businesses a customer is a company, in others a person, in others it could be either, and in one domain I worked a customer could have been either

A: A company
B: A department
C: An individual
D: A non physical entity such as a business process

All of which could also be a "Supplier". This is because they saw their Customers and Suppliers as things that consume and things that produce.

On the whole I personally found the book to be "a whole lot of nothing much at all", some of the personal stories were interesting but I also mainly found it repetitive and boring; a very difficult read. Unless the last 100 pages or so have something knock-out in them I expect I will remain very disappointed with it, if I ever manage to read the end that is.

Some people seem to be quite religious about this book, referring to it as "The book" and I feel by posting this negative review I might be opening myself up to attacks from DDD-extremists :-)

The fact is that I use parts of the DDD approach (now I at least know by what name to refer to it), it's just the book...


Domain driven design, Test driven design

I was just reading through the VBUG events list when I came across an event entitled "Domain driven design approach, using unit testing".

"Sounds interesting!" I thought to myself, I hope I can make it! As I started to read it I thought it looked familiar. At that point I realised it was me doing the talk! So hopefully I will be able to make it :-)

The posting is here. If you come along make sure you say "Hello".


Computer music

You may already know that I used to own a Commodore 64, and (as is nearly everyone else who ever owned one) I am still very passionate about the music people used to produce on it.

The question "Which was your favourite Commodore 64 tune" is a very hard one to answer as there are so many good ones out there, and people tend to go for the same short list "Delta", "Sanxion", etc.

However, recently I was creating some ambient background music for a presentation video. It started off a bit like a Jarre tune, but as I started to add in the percussion (for which I used samples of car doors slamming) it started to remind me of a tune from an old C64 game; "Tetris".

After downloading it and listening to it endlessly over and over as I write code I have come to a conclusion; TETRIS is my favourite C64 tune! It is just so unique, and unlike many other C64 tunes it hasn't aged, and doesn't actually sound that much like a C64 tune at all! Whenever I listen to it I feel like I am in the former USSR, building something out of strangely shaped bricks :-)

There's a (large) Mp3 of the tune here if you are interested.

Well done Wally Beben, you have in my opinion created a classic, and I will undoubtedly continue to enjoy it for many years to come. Actually, I am going to do a remix of it too, I hope he wont mind :-)


FireBird - Did it burn me?

This morning I spent an hour on the phone to Microsoft support. I tried to log into my machine only to see the error message

The user profile service failed the logon.
User profile cannot be loaded.

The guy on the phone got me to put my Vista install DVD into the drive, boot from that, go to system-recovery, and revert to a restore point. Worked nicely.

The thing is, why did this happen? The only thing I can think of is the open source Firebird DB server. I installed it on Sunday to get an old app to run (installed as app, not service). I didn't install the control panel plugin due to a warning on the site telling me not to install it on Vista or it will trash my Control Panel.

I suppose the warning about the control panel should have been enough to put me off. Still, it works now. I just wont be installing it again, at least for some time.


The importance of clarity

I wrote and now maintain a Pocket PC app for Imperial Tobacco (yes, despite supporting the ban on smoking in public places). It is important that the date/time on the PPC is accurate so part of the business flow is to get the user to check the date/time immediately after they log in.

Despite this step we were getting invalid dates back from their collected data, in all cases it was always one day ahead of the correct time. We have recently introduced various additional common sense checks such as "You have missed a working day, are you sure?" etc, but the change that will have the biggest affect is the one that was the smallest to change.

When the user enters the current date/time if it is less than the last known date/time on the server (sent in their database of work to do) I showed a message saying it was incorrect. The message read

"The date you have entered is invalid"

At this point the user looks at the date they have entered, thinks "but the date is right!", they click it forward a day and the PPC accepts it, so they continue with their work. Because I used the word "date" the user was blinkered to the value in the date, and didn't even bother looking at the time they had entered. The message now reads

"The date/time you have entered is invalid"

Hopefully this will be a bigger clue :-)


The ubiquitous language

One of the most important things to do when designing a system for a customer is to to try create a common business language between you and the people who understand the problem domain. A lack of what is known as "the ubiquitous language" can result in misunderstandings and a failed project.

I had a real life experience of a ubiquitious language failure yesterday. My brother went to the shop to buy some credit for his phone and offered to take my children with him to buy sweets. When they got back my son asked me

"How come uncle Stephen was able to buy credit for his phone?"

When I asked what he was talking about he described the sign on the wall in the shop, it read

"Please do not ask for credit as refusal often offends"