Whoah now, why would anyone want to think inside the box? That’s against corporate policy.
That’s not always the case, is it? The world recently observed the election of a new Pope, a process that took place entirely inside of a very closed space. The only communication to the outside world comes at the very end of the process as black smoke emerging from the Sistine Chapel:
During a papal conclave it’s important to deliberate inside the box. Similarly, the idea of thinking inside a Bounded Context is very important in the patterns of Domain-Driven Design, especially if you don’t want to be corrupted!
Bounded Context definition
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Apply Continuous Integration to keep model concepts and terms strictly consistent within these bounds, but don’t be distracted or confused by issues outside. Standardize a single development process within the context, which need not be used elsewhere.Model expressions, like any other phrase, only have meaning in context.
Learn why, when, and how to send smoke signals out of a Bounded Context box
Vaughn Vernon, a well-known Domain-Driven Design community leader, just published his new book, Implementing Domain-Driven Design, and the early reviews are very good. I met Vaughn at QCon 2010, in San Francisco, where he delivered a fantastic presentation called RESTful SOA or Domain-Driven Design – A Compromise? This presentation foreshadows the book, and in both he discusses and demonstrates how to integrate between multiple Bounded Contexts, using Domain Events (to be defined below) via the publication of RESTful AtomPub-based feeds. I encourage you to view his presentation video and slides. Read on for some quick highlights.
Three separate Bounded Contexts set the stage for integration
In both the presentation and the book, Vaughn focuses on building and integrating between Bounded Contexts within an Agile Project Management! How timely is that for a company like VersionOne and our users? In the book, a fictitious company named SaasOvation has an existing product named ProductOvation, which is comprised of the Agile Project Management Bounded Context. They are adding a new service to support group collaboration, which they begin to model and build out within the Collaboration Bounded Context.
Identity and Access Management Bounded Context is upstream from others
The third context, the Identity and Access Management Bounded Context is what you might expect: it’s for basic tenant and user info, and for authentication and authorization. As such, this context has information, like a person’s First Name and Last Name, that is upstsream and authoritative from the other two contexts. Vaughn’s presentation gives the example of a woman getting married and changing her Last Name. Since this is a change within the I & A Bounded Context that is of interest to downstream contexts, it must be published as a Domain Event that will be notified to the others. Those contexts that have data that must be updated based on the change will have to consume those events and then take appropriate, local action — all within the their own box.
Conceptual mapping between the Bounded Contexts with RESTful endpoints
To better understand this, the presentation shows the following Context Map with the three Bounded Contexts and the conceptual mappings between them. It’s important to understand these are not physical dependencies between concepts, but logical mappings between the different universes.
Staying pristinely clean and sanctified within an Anticorruption Layer
Because each context has its own, private universe that is not shared externally, it will not model everything the same way as others. For example, the TeamMember object in the Agile Project Management Bounded Context might use the Last Name value that came from the I & A context, but it might just have a single name field, or it might be called LName, or Surname. That is okay!
To keep the model clean within each context, DDD employs a pattern with my favorite name, the Anticorruption Layer:
As a downstream client, create an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model. This layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in one or both directions as necessary between the two models.
Here’s a diagram from Vaughn’s slides:
Domain Events are published when important things in one Bounded Context must be observed by external contexts
A newly added pattern since Eric Evans’ original Domain-Driven Design book from 2004, the DDD references describes Domain Events as:
Model information about activity in the domain as a series of discrete events. Represent. Represent each event as a domain object. These are distinct from system events that reflect activity within the software itself, although often a system event is associated with a domain event, either as part of a response to the domain event or as a way of carrying information about the domain event into the system.
A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain. Ignore irrelevant domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state change in the other model objects.
Read more about the addition of this pattern to DDD in the March, 2010 Domain Language newsletter.
Example Domain Event Notification as XML
While only viewing the video and slides can do the concepts justice, notice that in this slide, the Domain Event is PersonNameChanged. It’s very important to understand the past-tense nature of Domain Events. A Domain Event is something that has happened in a domain. It’s not something you can make un-happen. And, when we are talking about separate Bounded Contexts, the fact that something happened in the past is important because it can allow one context to subscribe to events from another. The subscribing context can respond by querying the source context for additional information related to the event, possibly to update local caches or the like. This can become the foundation for synchronization for systems the embrace eventual consistency.
In addition to Vaughn’s presentation, I highly recommend the presentations linked below by Greg Young. Greg has been very influential over the last five years in popularizing the DDD-related patterns of Event Stores and Event Sourcing. He has numerous free lectures on SkillsMatter about these subjects.
Other topics covered by the Implementing Domain-Driven Design book
See a full preview of the book from the Amazon link above. Here’s the summary:
Implementing Domain-Driven Design presents a top-down approach to understanding domain-driven design (DDD) in a way that fluently connects strategic patterns to fundamental tactical programming tools. Vaughn Vernon couples guided approaches to implementation with modern architectures, highlighting the importance and value of focusing on the business domain while balancing technical considerations. Building on Eric Evans’ seminal book, Domain-Driven Design, the author presents practical DDD techniques through examples from familiar domains.
Each principle is backed up by realistic Java examples–all applicable to C# developers–and all content is tied together by a single case study: the delivery of a large-scale Scrum-based SaaS system for a multitenant environment. The author takes you far beyond “DDD-lite” approaches that embrace DDD solely as a technical toolset, and shows you how to fully leverage DDD’s “strategic design patterns” using Bounded Context, Context Maps, and the Ubiquitous Language. Using these techniques and examples, you can reduce time to market and improve quality, as you build software that is more flexible, more scalable, and more tightly aligned to business goals. Coverage includes:
- Getting started the right way with DDD, so you can rapidly gain value from it
- Using DDD within diverse architectures, including Hexagonal, SOA, REST, CQRS, Event-Driven, and Fabric/Grid-Based
- Appropriately designing and applying Entities–and learning when to use Value Objects instead
- Mastering DDD’s powerful new Domain Events technique
- Designing Repositories for ORM, NoSQL, and other databases
Reprise: the papal conclave in a DDD perspective
Now that we have the terminology to think in the broad strokes of DDD, we can look at the recent papal conclave through that lens:
- The Sistine Chapel formed a Bounded Context, within which the private, internal state of the decision process took place. Its details were completely opaque to the outside world, and its many interested contexts.
- The rest of the Catholic world, the press, and the world at large represented other contexts.
- The black smoke represented a Domain Event, published to the external world after a significant event, for all interested parties to consume. Indeed, some parties were actively subscribed to this event with cameras. Upon viewing the smoke, they were able to initiate action to update their own local caches, so to speak, as soon as possible.
- The smoke signified a very real personNameChanged event all of its own! And, other observers, authors associated with bounded contexts like Wikipedia, were tuned in, ready to update the information cached at the canonical source of Pope Wikipedia entry
- Other external contexts, even those not so interested, will all become eventually consistent with the information that “Pope Francis” is now the name of the current pope. Some will become consistent by hearing it by searching the internet, others from the news, and still others won’t even become aware until someone directly informs them.
Want to study the book with others, and even get a free copy from VersionOne?
We’re starting a book club, for people in Atlanta and for anyone out there in remote-location-land. Check out this post for more information and to RSVP!
Resources for those very new to Domain-Driven Design
Much of DDD is really about things you already know, but with a set of common terms and practices for communicating with your stakeholders and other developers both in spoken language and as code. To learn more, you can always use http://dddcommunity.org/learning to find great resources, but here are a few highlights:
- DDD Pattern Summaries and Reference Definitions by Eric Evans and DomainLanguage (direct PDF link)
- Effective Aggregate Design — Parts I, II, and II by Vaughn Vernon (PDF, and two video presentations)
- RESTful SOA or Domain-Driven-Design — A Compromise? by Vaughn Vernon (Video and slides)
- Recovering the Ability to Design When Surrounded by Messy Legacy Systems by Eric Evans
- Architectural Innovation: Eventing and Event Sourcing by Greg Young
- Introducing the Event Store by Greg Young