Book Review: Domain-Driven Design

Book Review: Domain-Driven Design

I’ve just finished reading Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. Or to be more honest, I’ve finished skimming through it over the last couple of weeks whilst eating my lunch.

This book was recommended to me by an ex-colleague a whilst back. This fellow was an excellent technologist but was always a little…erm, how can I put this…minimalistic when it came to design and process. So when he recommended it, I figured that if he was keen on it, I’d better check it out.

It’s a big book, which in a time when everybody seems to be running around like blue arsed flies is perhaps a little detrimental to it. And at times – especially in the first half – it felt to me like a bit of a ramble. Now before you get too upset about me using the word ‘ramble’, I want to emphasize that I don’t mean it in the sense that a drunk would ramble at you in a pub. Instead, I am drawing more upon a definition of ‘ramble’ that the English sometimes use: a gentle wander through the countryside.

In other words: interesting, enjoyable but frankly something you do on the weekends when you want to relax; something that is a little bit of an indulgence, a brief step out of the daily rush. So I guess what I’m trying to say is that at times I couldn’t help thinking to myself: is a real software developer in the middle of a mad rush going to be able to use this stuff?

Don’t get me wrong, as an object-oriented programmer I think it all sounds terrific. And there are some interesting ideas in there. In particular, I liked the notion of ubiquitous language: consciously working your whole team – including the client – towards using a single set of terms and definitions for describing a particular domain and, even better, adopting this language directly into your domain model.

So should you read this book? Well, if you’ve got a bit of time up your sleeve, definitely. It seems to be becoming something of a modern classic in the same sense as Design Patterns. However, I’d take an approach learnt from years of design pattern (ab)use – don’t feel you have to apply it prescriptively. Instead, take a look at it, then forget it until you come across a problem that makes it spring back to mind. Then get it out again, and see whether it’s going to provide any immediate value.

That’s what I’m planning on doing.

I'm a Senior Consultant at Shine Solutions.

No Comments

Leave a Reply