Home >

Domain-Driven Design Immersion Course – Part #3

1. March 2010

By far the most neglected aspect of DDD is Strategic Design. I have found that most people who read the DDD book are captivated by the first section on design and modeling, but start getting bogged down in the details of the building block patterns in the second section. Many people never even making it to the strategic design section of the book in part 4. For this reason, I always encourage people to read the parts in the sequence: 1, 4, 2, 3 – I think the building-block patterns, being tactical in focus, make much more sense in light of the strategic patterns in part 4.

I should reiterate that I’m not going to try to cover everything we talked about in the class, and not even most of it. I am simply mentioning highlights and reflecting on what I experienced and learnt, and how I see these things helping me in future. The quotes below are typically from Eric or the course notes as we worked through the day.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series:

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Day 3 – Strategic Design

The third, penultimate, day was all about strategic design in DDD. Strategic design ultimately provides the vision, context and direction for tactical design (which – as I mentioned - includes the building-block patterns and refactoring the deeper insight sections of the DDD book in part 2 & 3). Without paying attention to strategic design patterns such as Core Domain, Bounded Context, and Context Mapping, a team new to DDD is likely to spend a great deal of effort doing modeling and design poorly and – more importantly - in the wrong places. Doing good work solving the wrong problem is just as much a problem as doing bad work.

051Eric talked about how strategic design is all about aligning the design effort with the business direction and vision, making sure that the most-experienced and most-capable people are working on the areas that are most critical to the competitive advantage, and thus success, of the business. As a class, we discussed how it is natural for developers to gravitate towards the latest technology or framework or tool, but that these are very much secondary concerns compared to making the design of the system best where it is most likely to positively impact the business both now and beyond.

This part of the class showed me how much more effort I need to put into strategic design. I realize now that a number of the struggles I have faced in my past DDD work is exactly because I did not give this area the attention that it deserves. And I think this is understandable, as I mentioned above, because of the sheer volume of new ideas, mindset changes, patterns and skills that have to be developed just to master the tactical aspects of DDD such as the building block patterns and Ubiquitous Language. I spent some time yesterday reflecting on a recent architectural review I did with a client, and decided that I need to perform a context mapping exercise for that system in order to better understand the system and busienss contexts. I see now the value in improving my skills in this area, because of the value that context mapping brings to the design area.

If you look at the Wikipedia entry for Domain-Driven Design, the Strategic Domain-Driven Design section is mentioned first (the diagram there, taken from the book, is very helpful in seeing the bigger picture). I should mention that it is the NYC DDD meetup group that has primarily been the ones working on improving the Wikipedia entry for DDD.

A DDD Play: The Mystery of Peerless Shipping

050Much of day 3 is structured within the framework of a play. A roleplay. With scripts and characters to act out. A mystery play. We really got into the acting and the characters and had a lot of fun with it. If you take the course, I would encourage you to have fun with the roleplay – you will get a lot more out of it (and learn a lot more in the process). 

It wasn’t hard to relate to the situations that the characters found themselves in. What was hard, though, was seeing a way to understand their situations and how DDD might help as we worked through each Act in the play and acted out the parts. We struggled to understand how to get the characters out of the difficult design and organizational situations in which they found themselves. But this is where the discussion with the instructors after each Act really drove the point home.

Eric and Kristian guided us through each of the major strategic design patterns, showed how they applied to each aspect of the system and organization, and enabled us to see the way forward in each 048case. By the time we were done, I felt like I finally had a coherent structure and language for describing and understanding the variety of team and design situations/arrangements, and a proven approach for making improvements where they are likely to do the most good.

Patterns such as Conformist, Anti-Corruption Layer, Customer/Supplier, Share Kernel and (a new one) Partnership enabled us to see where the issues were and know how best to address them. I was familiar with these from reading the DDD book a few times, but it wasn’t until I took the course this week and went through the roleplay with the other students that it finally “clicked” for me. I realize I need to really grok these patterns, and learn to apply them in every client engagement.

We are IT people. We love to abstract and we love to unify. But there are always multiple models.

053One of the tendencies we all have – which is often reflected in the vain pursuit of Enterprise Data Models - is to try to represent all the complex and variagated concepts and data within our organizations as one abstraction. In doing so we reduce the concepts to the lowest common denominator, stripping them of their meaning, significance, and power in the process.  They become emaciated, anemic models that don’t help anyone.

Alternatively, we ignore – at our peril – the many diverse contexts in the business, and thus the different meaning of things between systems and tend to miscommunicate and make subtle, costly and difficult-to-find mistakes when we try to intergrate them. This leads to the type of situation where you request a certain thing from another system expecting one thing, and get smoething with the same name that means something completely different. Which is why Eric says:

In software integration there are no happy surprises.

Language is made up of words, words that represent concepts, and concepts only have a meaning within a specific context. This is where Bounded Context and Context Mapping come in.

In business you will find that there are lots of contexts, and everything is working fine. Whenever shipping people are talking to marketing people about a customer, everyone understands that there are different contexts.

In software we have to make this completely explicit.

Eric said that when he gets involved with a new client, one of the first things he does is draw a context map. This describes what models are being used, and what are the boundaries. Each of these boundaries will typically be a subsystem boundary, or a boundary that a team is particularly working on. He strongly stated that we should not try to invent anything new in the Context Map:

The purpose of a Context Map is to try to reflect the way things are right now.

"Map what is" - we need to constantly be reminding ourselves of this. it feels unnatural to do this, we are problem solvers by nature.








Another important idea here for me was the notion of Upstream/Downstream. We typically use these words to denote data flow, or technical dependencies. But DDD uses them in a very specific way, related more to organizational dependencies, one that helps make sense of the various strategic design patterns in DDD:



Upstream-Downstream (p. 34) - A relationship between 2 groups in which the "upstream" group's actions affect the downstream group, but the actions of the downstream do not affect the upstream (e.g, If 2 cities are along the same river, the upstream city's pollution primarily affects the downstream city)

Continue to Part Four – Strategic design (continued) – Core Domain.

Go back to Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc).

Pingbacks and trackbacks (2)+

Comments are closed