Wednesday, 30 March 2016

Book Study: Patterns-Principles and Practices of Domain Driven Design

Book Study: As title


In summary this is an excellent book.  It is really accessible but some of the more advanced areas will need further reading elsewhere. For example, things like Aggregate design 

If you are involved in Enterprise application development and you haven't yet been able to take advantage of the Domain Driven Design (DDD) philosophy, this book will show you the way. I know this because it is almost like a narrative to my experiences of the philosophy at a large e-commerce website in terms of some of the problems experienced, practices adopted, conversations with the business and stakeholders, patterns used, misused, abused and not used and every conversation about everything in DDD in-between.

Go Compare

I previously read the fist 3 chapters  of Vaughn Vernon's Implementing DDD book and I ran out of steam for various reasons (the birth of my second son primary amongst them). Its not that it isn't a good book (I refer to it later on and why I think this is the case) but it felt a little bit formal and dry on occasion and I'm sorry to say the cowboy logic comic strips both confused me and grated with me, maybe you have to be an American to understand the jokes.  

Keen to still learn further about DDD and, on the recommendation of a friend, I'd picked up Patterns Principles and Practices of Domain Driven Design (PPPDDD - I know!!!)  after seeing an example of using Atom Feeds and HTTP to provide a reactive messaging  solution as an alternative to using a message bus.  This was a great antidote to having a particular service bus, which will rename nameless, rammed down my throat for the last 2 years as the way to "do asynchronous" messaging.

The language and concrete examples in the section seemed a lot more accessible than some of the stuff in Vaughn's book and so I decided to study it from cover to cover - doing as much of the code examples from scratch reading all of the stuff about strategic patterns and drawing out designs, before moving on to the less subjective tactical patterns and other patterns this book has to offer an opinion on.  

What followed was an epic 6 month journey where I ended up cross referencing the Vaughn's book, blogs and everything in between to try and get a better handle on DDD. 

After all this, I am only bit wiser about DDD, although I can now hold my own in a conversation on the subject and suggest a few patterns, decomposition techniques and identify domains, sub-domains and bounded contexts, it is clear that it will take me many years and experience of certain situations to be truly conversant and comfortable with DDD, and this book is only going to get you some of the way, actual real world experience is going to have to back up what is learnt in this book, otherwise you will lose what you have learnt. 

This might be ok, you might never need to do context-mapping at your current job with all of the seams and domains and sub-domains identified already, but having a deeper insight into what affects this kind of arrangement, as well as many other aspects, are key to having ammunition to engage with the business and help drive solutions to new problems that emerge in your business's domain.

The Book

There is so much stuff in this book I started writing notes and actually ended up taking about 100 pages of notes as well as creating about 5 solutions and posting gists of useful code examples to pinch for future use, I started this post the same day I wrote my post about Twitter in October last year.  It's taken me an age.  

There are 4 main parts covering:

  • Part 1 - The Principles and Practices of Domain Driven Design
  • Part 2 - Strategic Patterns: Communicating between bounded contexts
  • Part 3 - Tactical Patterns: Creating effective domain models
  • Part 4 - Design patterns for effective applications
I will discuss a few of the highlights of the parts, I will not go into too much detail,  but because of this I will be doing some of the book a disservice, so if reading this leaves you asking questions  (which it probably should) then buy the book!

Part 1 - The Principles and Practices of Domain Driven Design

The main thrust of this part is about DDD as a philosophy, what it is and isn't and that it isn't just about tactical patterns and when and where DDD should and shouldn't be applied.   

This part clearly spells out what things like the Ubiquitous language is, how to decompose complex problems into more manageable ones,  getting buy-in from the business, collaboration, context-mapping and what a bounded context is, to name but a few things. The very essence of what DDD is, is covered and you wont be left scratching your head after. 

This part of the book is very insightful and as a developer I was initially tempted to skip past large parts of this part, but doing this  - it quickly became clear - would mean I would be missing the point of DDD. I would recommend you do the same if you want to start to grasp it properly. 
There is so much which resonates in this chapter in terms of  what engaging with stakeholders is like, advice on managing the expectations and of stakeholders and advice  on stopping stakeholders jumping to solutions and keeping them focused on the problems in the domain and in the language of the domain and things like mapping a problem to a model of the problem.  The break down of what a core domain, domain, sub domain and a bounded context are, is indispensable too.   I personally found decomposition hard to understand  before I read this, and the chapters guide you through decomposition in a very clear manner.

Suffice it's to say, I don't agree with everything here though, some of the bounded context modeling is not how I would model bounded contexts necessarily, as some of the naming relies on the domain messages they receive, but the decomposition aspect of this exercise is the main point here.

There is lots of ground to cover and, if I am being honest, I would have to refer back to my notes (or the book) to help me remember large parts of this section in detail and here in lies a problem with a book of this magnitude, its really not possible to retain all of  its contents to a high level of detail and I'd recommend referring to it as a reference depending on your needs in a project.

Part 2 - Strategic Patterns: Communicating between bounded contexts 

As a developer the real fun starts here, after a lot of scene setting and ideological imparting in the first part,  this part focuses on some examples of getting bits (bounded contexts) of a domain (or other sub-domains) to talk to each other.  Using NServiceBus, EventStore and Atom Feeds for various types of communication between bounded contexts, the examples are clear and really help bring to life what and how reactive messaging  and RPC can be used to create solutions that communicate effectively.  Reading this you may wonder why RPC might even be a consideration these days, but it was an eye-opener to see that this should still be a worthy consideration.  If anything, this book helps you keep an open mind and you can practice your "it depends" come back when talking to colleagues about potential solutions to problems. 

A small gripe with this section is the fact that HAL (Hypermedia Application Language) is introduced as a basis for the messaging with atom feed event examples without a real good reason as to why it is introduced or used. Don't get me wrong it seems like a useful implementation of HATEOS but probably wasn't necessary for the examples.  

Part 3 - Tactical Patterns: Creating Effective Domain Models

This was my favourite part of the book, as a developer, it has stuff that I can use in my day to day and indeed some of the stuff I learnt here is out in the real world shortly to be used by millions of customers (albeit a small thing, but nevertheless) .   The examples around value types are great and although I had an understanding of what they were - again - I was left with no ambiguity in my understanding.   Likewise the clear distinction between domain services and application services is excellent. These two concepts were a blur to me before but now stand distinguished - side by side. Event sourcing is described in detail and is a good as guide as any I have seen.   The bit I was looking forward to the most was the chapters on Aggregates.  These are one of the fundamental tactical tenets of DDD and they are given thorough treatment here.   From what an invariant is to determining aggregate boundaries and considerations on when and where to use immediate and eventual consistency.   I must admit though that I cross referenced Vaughn's book here because he does provide more insight and consideration. It is worth saying that when I come to design aggregates I will refer back to both books to give me as much chance of modeling them correctly as possible. 

Part 4 : Design Patterns for Effective Applications

The stand out chapters of this section is the treatment of CQRS. Again, an area I am pretty au-fait with but this left me with no doubt about its applicability in certain situations and it left me crying out loud as to where we could have adopted it in some of the work we applied DDD to at work recently. We didn't go the whole hog in generating a simple read model and got a little confused between our write and read concerns 
Application and domain services are worked through well with good examples. However, one of my major gripes with some of the application service examples is the seemingly poor choice of aggregate design to show application service co-ordination, which was bit of a shame.  The example involved a customer referral example and saw an application service updating 2 separate aggregates in the same transaction which is generally advised against (but not always) in chapters in the previous part of the book.  I can see that the authors chose to really highlight co-ordination here but I think a more expansive example of eventual consistency and immediate consistency would have really helped and not meant I had to go looking in Vaughn's book. 
There are also chapters on reporting, by this time I was ready to put down the book but managed to see it through. 

If you want an accessible book and want to have a good grounding with DDD as a philosophy I would highly recommend this book. 
As far as I know all major angles of DDD are covered from both a design and implementation point of view, with a nice collection of current and relevant technologies covered.  The book comes more from a practitioner point of view and is less formal in it description of the various aspects of DDD as compared to say the blue or red book (Evans and Vaughn's books respectively)  the authors don't use the  this/that pattern(54)  calling out of patterns etc and some may consider it a little bit less high brow than the other books.  On this note some of the more advanced things like Aggregates could probably do with more examples, as with all of these books real world examples are thin on the ground.  The contrived example of SaaSOvation in Vaughn's book although obviously contrived doesn't easily map well to some of the problems found in more e-commerce web applications, but there is enough there as food for thought.  If this post seems a bit weary, it is, I could barely muster the energy to regurgitate what it is I learnt after a long haul.  I think I'll have to revisit this post when I revise some of the material to give the book the justice it deserves.  
In contrast to this marathon study, I  read the Software Craftsman by Sandro Mancuso in 2 days after this, and felt inspired and pumped this will be the subject of my next post. As one of my famous colleagues would say "I better go and do some work  

No comments:

Post a Comment