Bernie Cook's Blog

Azure, C#, .NET, Architecture & Related Tech News

Book Review: “Implementing Domain-Driven Design″

5 Comments

Implementing-Domain Driven Design CoverI’m a big fan of the Domain-Driven Design (DDD) principles and patterns so pre-ordered Vaughn Vernon’s “Implementing Domain-Driven Design” prior to it’s release in March this year (2013). Having finished it earlier this week I wanted to do some justice to this invaluable text by posting a blog which provides a synopsis of each chapter, as well as some general commentary about the book.

If you don’t read any further let me say, before you go, that if you’re interested in learning about DDD, or want a modern and comprehensive DDD reference book, then get your hands on a copy. This text easily gets a 5 star rating from me, which is akin to the ratings on Amazon.com and Amazon.co.uk at the time of writing.

A Few Brief Notes

Implementing Domain-Driven Design is a very comprehensive book on DDD, to say the least, and will serve it’s owners well as a reference text just as much as it will as an informative guide to DDD. There is a sample solution that runs throughout the book so each chapter makes some pertinent reference to how the topic at hand can be applied to the solution. If you’re a C# developer don’t be too alarmed that Java is the language of choice throughout the book, I haven’t touched Java in years and I managed to keep up (for the most part :)). One thing I will say is if your not familiar with a lot of the more common design and architectural patterns in use today either be prepared to learn them as you go, or do some preliminary swatting up – they’re littered throughout the book as you can expect.

All up the book covers a lot of ground and personally I think the author did an excellent job. Even when summarising the chapters I found that I was leaving quite a bit out as they’re all so incredibly comprehensive. If there was anything I would change it’d be making a reference to my favourite IDE and tools throughout, but I acknowledge that doing so would more than likely drive the Java readers mad so I don’t fault the author for his choice.

In a lot of ways DDD can be seen as a tool for architects and developers and I personally felt better equipped to use my DDD tools and skillset out in the real world after having read “Implementing Domain-Driven Design” by Vaughn Vernon.

Chapter Overview

1. Getting Started with DDD

This chapter introduces a broad number of DDD terms, but nothing as involved as what follows in subsequent chapters. Also included is a brief review of how to evaluate projects, some sample hand-ons pointers as to how improvements can be addressed via DDD practices, and an introduction to a sample team and their projects which will be referenced throughout the book. All up it’s a great chapter and I was impressed at how engaging Vaughn Vernon managed to make it. You come away with a broad idea of how involved and encompassing DDD is with a number of practical illustrations along the way.

2. Domains, Subdomains, and Bounded Contexts

As the title suggests Domains, Subdomains and Bounded Contexts get a very thorough work over – all of the main elements of a DDD strategic design. Core Domains, Supporting and Generic Subdomains, are also addressed as well as why it’s important to adopt a strategic design approach when analysing the problem and solution spaces. Each section contains a number of short hands-on workshops, and direct questions you can answer to better understand each concept and it’s relevance to a solution you are, or may be about to, work on. A number of common strategic design pitfalls to avoid are raised as well as a strong emphasis on key factors not to misinterpret or misunderstand.

3. Context Maps

This chapter focuses on the solution space (as opposed to the problem space discussed in the previous chapter) which brings to light the concept of Context Maps; how two Bounded Contexts are related. This benefits the solution design as well as helping map out Bounded Context communication and inter-team communication on larger solutions where each team is responsible for a given Context. As well as covering all of the essential terminologies and business practices that are associated with Context Maps the author provides a detailed overview of how Context Maps are applied from high-level diagrams down to the source code.

4. Architecture

This is quite the comprehensive chapter, and a very well presented one. As the name suggests it’s about architecture and covers a lot of architectural patterns relevant to enterprise solutions as well as making reference to what approaches to take with medium-scaled solutions where the complexity and demand is less involved. The list of topics covered is quite comprehensive so I’ll provide an abbreviated list; Layer Architecture (before and after DI is introduced), Ports and Adapters Architecture (Hexagonal/Onion), use-case driven and event-driven architecutre, CQRS, sagas, SOA, REST, grid-based distributed computing etc.

5. Entities

The fundamentals as to what constitutes an Entity and how it’s utilised in a DDD solution are covered. Related topics such as Entity identity generation (and considerations), validation, how each particular Service or tiers interact with Entities, and some practical implementations of Entities as well as influences by some modern day frameworks and data stores are also discussed.

6. Value Objects

Value Objects, programmatic and design concepts that “describe a thing in the domain” (p.221) are covered in detail. It gets a good deal of coverage as it’s correct application over Entities is of great benefit in a DDD solution. Side-effect free behaviour, Whole Value replacement, immutability, initialisation, value equality, no requirement for a unique constraint, easier to test and maintain, no restriction on size or complexity, etc. are all addressed.

7. Services

Covering both Application services and Domain services, providing solid definitions and ample architectural and code examples. As noted by the author it’s important to understand what a “service” is, and what it is not, when constructing a DDD solution so that you avoid incorrect practices that can lead to anaemic domain models and other anti-patterns. Some attention is paid to service testing as well.

8. Domain Events

Domain Events are considered part of the larger domain model as they are something that occurs within the Domain. Because Domain Events can be implemented in a number of ways, each requiring a high level of system design understanding, the chapter does delve into more complexity than some of the previous chapters. You’ll certainly come away with a better understanding of Domain Events and the scalability it provides but will definitely need to do some extra reading to know how best to apply them in a given solution – this isn’t a critique, there are simply a lot of ways to implement this particular DDD element.

9. Modules

This is one of the shorter chapters, given it’s not really the first thing that springs to mind when you think about DDD. However constructing modules is still a key element to solution design so it’s good to know it’s given ample attention. Cohesive, low-coupled, modules are discussed, general guidelines to follow, the importance of introducing the Ubiquitous Language into the naming of modules, all with reference to both Java and C#.

10. Aggregates

My understanding of Aggregates, prior to reading this chapter, was based on a number of other sources who never explained it as well, or in as much detail as Vernon Vaughn so I came away from this chapter with a more comprehensive understanding of Aggregates than I’d had before, and learnt a few new modelling techniques along the way. Aggregate modelling, Aggregate relationships, root Aggregates, size considerations, true/false invariants, transactional handling, transactional/eventual consistency, etc. are all covered. Great chapter.

11. Factories

Using factories in the domain model is the focus (… as you’ve probably guessed) regardless of the specific design pattern; Abstract Factory, Factory Method or Builder. A very short chapter that covers the essentials.

12. Repositories

The illusionary in-memory data store of objects 🙂 is given ample attention in this chapter. Both the common approach of one-to-one repository-to-aggregate approach is covered as well as the not so common approach when a single repository covers more than one Aggregate type. An abundance of Hibernate examples are provided, as well as a few TopLink (UoW), with regards to repository collection-oriented design. In contrast the other type of Repository design; persistence-oriented design, is also given quite a bit of attention with a NoSQL approach (namely MongoDB). A number of very helpful tips are provided to address the less standard Repository design scenarios as well as a robust testing approach. I could go on but suffice to say this is a very comprehensive chapter.

13. Integrating Bounded Contexts

A very detailed coverage of integrating distributed environments, with particular emphasis on RESTful HTTP and messaging mechanisms. A lot of attention is paid to the latter and there are no shortage of code samples. All up it’s a very detailed chapter with ample theory, considerations and recommendations to put into practice.

14. Application

A very, very informative and well presented chapter. The main focus is on the Application Layer with attention paid to it’s responsibilities, the layers on either side (UI, Domain), and how they all work together … in a loosely coupled fashion that is :).

Appendix A. Aggregates and Event Sourcing: A+ES

The Appendix is contributed by a separate author that builds on top of Vernon’s text, covering the topic of Aggregates and Event Sourcing.

Final Notes

Vaughn Verson has a website at vaughnvernon.co/ and a GitHub repository github.com/VaughnVernon/ if you’re interested. The latter has the sample code from the book which is something that I didn’t find referenced in the text.

If you purchase the hard copy of the book then Safari Books Online provide 45 days access to an online copy – note that’s “online copy”, not an electronic copy that you can save locally. Darn.

As noted earlier this is a great book, and I would recommend picking it up if you enjoy using DDD, or are an experienced software engineer looking to learn more about DDD.

Enjoy.

Author: Bernie

I currently live and work in the UK, just outside of London. I've been working in IT for 15+ years and in that time have solved many technical problems via blogs, forums, tutorials etc. and feel like I should be giving something back. This blog post is my way of contributing and I hope it proves just as useful to others as their contributions have to me.

5 thoughts on “Book Review: “Implementing Domain-Driven Design″

  1. Very complete review! I am half way through the Blue Book and already proclaimed myself as ddd only from now on. I also bought myself a copy of Implementing DDD and I am so confused now. Should I switch books now and leave the blue book for later? Past the introduction everything is just patterns and that demands much slower reading. Which book would you recommend first?

    • Thanks Francisco. I’m a big supporter of DDD myself and although I would like to read the Blue Book I skipped over it, partly for time reasons and partly because I found the answers I was seeking from other sources – one being the book reviewed above. As such I can’t really comment on how much I’d recommend reading the Blue Book itself.

      Having said that I did find “Implementing DDD” incredibly useful as it dives into all DDD concepts, practices and patterns – so it’s a great way to come away with a solid grounding in DDD theory, and to find some answers to conflicting approaches that are usually discussed on the web. Keep in mind that you may not be able to get away with just reading “Implementing DDD” by itself and feeling you know DDD inside and out as the frameworks you use play a big role. I found it useful for the theory and the patterns and practices to follow then combined it with other architectural patterns and approaches such as Onion Architecture and Distributed solution design.

      If it’s of any help take a quick look at this PDF – “DDD NLayered .NET 4.0 Architecture Guide” (http://msdn.microsoft.com/es-es/architecture/gg189193) as it might give you some initial guidance if you’re using DDD in the .NET field. It provides some very simplified (if sometimes too simplified) coverage of DDD which is a good starter.

      If you have any other questions do feel free to ask. I remember being in the same position at one point and had to do a lot of reading and proof of concept work to sharper my DDD skills.

      • In my search for DDD videos I noticed that in three of them the speaker asked: Who have read the DDD book? Who have read past chapter 7? And after noticing how many hands went down, I decided to do the same. Now I understand

        The first 7 chapters of the blue book give you in ca. 150 pages a good overview of DDD ending with a nice example of how DDD looks like. That is the way I felt in love with DDD

        Now IDDD is kind of bittersweet book. Lacks many things I wanted to know, but it is almost too long already. It is a better introduction to DDD but I believe people should start with the blue book.

        IDDD is great for people who already grasp DDD. The chapters are more didactic and cover lots of details. It lends itself to be read from beginning to end. I am trying to do a quick overview of the book and decide what to postpone, but I lack the knowledge to take wise decisions. I want to start a new DDD oriented project as soon as posible, and the right chapters for that are at the very end.

        My biggest interest is building something with an hexagonal architecture, CQRS pattern, repositories with more than one backend and at the same time, database agnostic, most likely by using different sets of data mappers. At the same time should have some Polyglot persistance mapping to NoSQL and SQL stores at the same time…

        … yeah, to big to chew, but I believe that if I manage to start no CQRS, single database repository with data mappers I will have the right foundation that will allow me refactoring slowly to that.

        Sadly it seems that IDDD will not talk about repository-data mappers, the relation of events/repositories with the unit of work pattern and NoSQL map reduce functions. Repositories seems a great place for that, but data mappers might be even a better place. I am starting to feel that there is still a gap between PEAA (Fowler), DDD and IDDD considering NoSQL

        Thanks a lot for the offer to answer some questions, but before that I should start a new project, finish along the way that book and feel better the basics. So far I decided to delay learning too much about events (specially stores) and start with a simple aggregate/repository and play with GUI / Domain services. It seems that with that alone, it will be easy to introduce the rest as I learn more about them… and should not wait to finish IDDD before my first lines of code!

  2. ops, forgot to say that if CQRS seems like “overkill” for beginners, I am wildly curious about why it is so good for NoSQL/DDD

    http://stackoverflow.com/a/5753979/253098

    Also, I noticed how useful a DSL could be and found this…

    https://sites.google.com/site/fornaxsculptor/

    grrrr! so much to explore! Although that seems Java only oriented

    • I find the hardest thing is having enough hours in a day to absorb and get hands on with a lot of these exciting frameworks and practices. Sure you can delegate a lot of it but that’s not as much fun as learning it all.

      Can’t we get someone to work on extending days from 24 hours to 36 … perhaps reducing the rotational rate of the planet 🙂

Leave a comment