Journey 2: Decomposing the Domain
|On this page:||Download:|
|Definitions used in this chapter | Bounded contexts in the conference management system | Why did we choose these bounded contexts?|
Planning the stops.
"Without stones there is no arch." Marco Polo
In this chapter, we provide a high-level overview of the Contoso Conference Management System. The discussion will help you understand the structure of the application, the integration points, and how the parts of the application relate to each other.
Here we describe this high-level structure in terms borrowed from the domain-driven design (DDD) approach that Eric Evans describes in his book, Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional, 2003). Although there is no universal consensus that DDD is a prerequisite for implementing the Command Query Responsibility Segregation (CQRS) pattern successfully, our team decided to use many of the concepts from the DDD approach, such as domain, bounded context, and aggregate, in line with common practice within the CQRS community. Chapter 1, "CQRS in Context," in the Reference Guide discusses the relationship between the DDD approach and the CQRS pattern in more detail.
Definitions used in this chapter
Throughout this chapter we use a number of terms, which we'll define in a moment. For more detail, and possible alternative definitions, see Chapter 1, "CQRS in Context," in the Reference Guide.
Domain: The domain refers to the business domain for the Contoso Conference Management System (the reference implementation). Chapter 1, "Our Domain: The Contoso Conference Management System," provides an overview of this domain.
Bounded context: The term bounded context comes from Eric Evans' book. In brief, Evans introduces this concept as a way to decompose a large, complex system into more manageable pieces; a large system is composed of multiple bounded contexts. Each bounded context is the context for its own self-contained domain model, and has its own ubiquitous language. You can also view a bounded context as an autonomous business component defining clear consistency boundaries: one bounded context typically communicates with another bounded context by raising events.
Context map: According to Eric Evans, you should "Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing." This exercise results in what is called a context map, which serves several purposes that include providing an overview of the whole system and helping people to understand the details of how different bounded contexts interact with each other.
Bounded contexts in the conference management system
The Orders and Registrations bounded context:****Within the orders and registrations bounded context are the reservations, payment, and registration items. When a registrant interacts with the system, the system creates an order to manage the reservations, payment, and registrations. An order contains one or more order items.
A reservation is a temporary reservation of one or more seats at a conference. When a registrant begins the ordering process to purchase a number of seats at a conference, the system creates reservations for that number of seats. Those seats are then unavailable for other registrants to reserve. The reservations are held for 15 minutes, during which time the registrant can complete the ordering process by making a payment for the seats. If the registrant does not pay for the tickets within 15**minutes, the system deletes the reservation and the seats become available for other registrants to reserve.
The Conference Management bounded context: Within this bounded context, a business customer can create new conferences and manage them. After a business customer creates a new conference, he can access the details of the conference by using his email address and conference locator access code. The system generates the access code when the business customer creates the conference.
The business customer can specify the following information about a conference:
- The name, description, and slug (part of the URL used to access the conference).
- The start and end dates of the conference.
- The different types and quotas of seats available at the conference.
Additionally, the business customer can control the visibility of the conference on the public website by either publishing or unpublishing the conference.
The business customer can also use the conference management website to view a list of orders and attendees.
The Payments bounded context:****The payments bounded context is responsible for managing the interactions between the conference management system and external payment systems. It forwards the necessary payment information to the external system and receives an acknowledgement that the payment was either accepted or rejected. It reports the success or failure of the payment back to the conference management system.
Initially, the payments bounded context will assume that the business customer has an account with the third-party payment system (although not necessarily a merchant account), or that the business customer will accept payment by invoice.
Bounded contexts not included
Although they didn't make it into the final release of the Contoso Conference Management System, some work was done on three additional bounded contexts. Members of the community are working on these and other features, and any out-of-band releases and updates will be announced on the Project "a CQRS Journey" website. If you would like to contribute to these bounded contexts or any other aspect of the system, visit the Project "a CQRS Journey" website or let us know at firstname.lastname@example.org.
The Discounts bounded context: This is a bounded context to handle the process of managing and applying discounts to the purchase of conference seats that would integrate with all three existing bounded contexts.
The Occasionally Disconnected Conference Management client: This is a bounded context to handle management of conferences on-site with functionality to handle label printing, recording attendee arrivals, and additional seat sales.
The Submissions And Schedule Management bounded context: This is a bounded context to handle paper submissions and conference event scheduling written using Node.js.
Wait listing is not implemented in this release, but members of the community are working on this and other features. Any out-of-band releases and updates will be announced on the Project "a CQRS Journey" website.
The context map for the Contoso Conference Management System
Figure 1 and the table that follows it represent a context map that shows the relationships between the different bounded contexts that make up the complete system, and as such it provides a high-level overview of how the system is put together. Even though this context map appears to be quite simple, the implementation of these bounded contexts, and more importantly the interactions between them, are relatively sophisticated; this enabled us to address a wide range of issues relating to the CQRS pattern and event sourcing (ES), and provided a rich source from which to capture many valuable lessons learned.
Figure 1 shows the three bounded contexts that make up the Contoso Conference Management System. The arrows in the diagram indicate the flow of data as events between them.
Bounded contexts in the Contoso Conference Management System
The following list provides more information about the arrows in Figure 1. You can find additional details in the chapters that discuss the individual bounded contexts.
- Events that report when conferences have been created, updated, or published. Events that report when seat types have been created or updated.
- Events that report when orders have been created or updated. Events that report when attendees have been assigned to seats.
- Requests for a payment to be made.
- Acknowledgement of the success or failure of the payment.
Why did we choose these bounded contexts?
During the planning stage of the journey, it became clear that these were the natural divisions in the domain that could each contain their own, independent domain models. Some of these divisions were easier to identify than others. For example, it was clear early on that the conference management bounded context is independent of the remainder of the domain. It has clearly defined responsibilities that relate to defining conferences and seat types and clearly defined points of integration with the rest of the application.
On the other hand, it took some time to realize that the orders and registrations bounded context is separate from the Payments bounded context. For example, it was not until the V2 release of the application that all concepts relating to payments disappeared from the orders and registrations bounded context when the OrderPaymentConfirmed event became the OrderConfirmed event.
More practically, from the perspective of the journey, we wanted a set of bounded contexts that would enable us to release a working application with some core functionality and that would enable us to explore a number of different implementation patterns: CQRS, CQRS/ES, as well as integration with a legacy, CRUD-style bounded context.