Tonight Paul Rayner presented on some of DDD’s essential strategic design elements, Bounded Contexts and Context Mapping. This was also the topic of my REST with DDD QCon presentation back in November 2010. Paul is one of Eric’s DDD Immersion instructors, and so he carries a well-rounded understanding into his material. It’s great to have Paul and Randy Stafford as co-organizers with me.
Paul’s presentation led into a good discussion on the practical use of Context Maps in various projects. As a result, I offered an example enterprise that faces interesting modeling challenges. I used a publishing organization that must deal with the various stages of the life cycle of books. Roughly speaking, publishers deal with stages similar to these:
- Conceptualizing and proposing a book
- Contracting with authors
- Managing the book’s authorship and editorial process
- Designing the book layout, including graphic illustrations
- Translating the book to other human languages
- Producing the physical print and/or electronic editions
- Marketing the book
- Selling the book to resellers and/or directly to consumers
- Shipping a physical book to consumers
I discuss this in Chapter 2 of my upcoming DDD book. The following is an excerpt.
Throughout each of these stages, is there one single way to properly model a Book? Absolutely not. At each of these stages the Book has different definitions. It is not until contract that the Book has a tentative title, which might change during editorial. During the authorship and editorial the Book has a collection of drafts with comments and corrections, along with a final draft. Graphics design creates page layouts. Production takes the layouts and uses them to create press images, “blue lines,” and finally plates. Marketing doesn’t need any of the editorial or production artifacts. And to shipping, the Book might carry only an identity, inventory location, availability count, a size, and a weight.
What would happen if you tried to design a central model for Books that facilitated all the stages in its life cycle? There would be a high degree of confusion, disagreement, contention, and little deliverable software. Even if a correct common model could be delivered from time to time, it would likely meet the needs of all clients only occasionally and far too briefly.
To counter that kind of undesirable churn and burn, such a publisher should use separate bounded contexts for each of the above life cycle stages. In each of the unique bounded contexts, one domain object in each could be named Book. While the various Book objects would share identity across all or most of the contexts, most Book compositions would be vastly different from each of the others. That’s fine, and in fact the way it should be. When the team of a given bounded context speaks about a Book, it means exactly what they require for their context. The organization embraces the natural need for differences. This is not to say that such positive outcomes are trivial to achieve. Nonetheless, using explicit bounded contexts, software gets delivered regularly with incremental improvements that address the specific needs of the business.
This excerpt doesn’t get into modeling the full solution, but it did provide a good way to discuss what each of the models might be like. Whenever you face a similar challenge in your business, consider using this example, especially if you aren’t in book publishing. It will allow participants to take a step back and consider things from a different perspective. It sure enabled a lot of good discussion for our meetup group, and many got over the hurdles they faced in understanding the need for using separate bounded contexts in every DDD project.
