Skip to content

Latest commit

 

History

History
193 lines (161 loc) · 6.87 KB

Journey_02_BoundedContexts.markdown

File metadata and controls

193 lines (161 loc) · 6.87 KB

Chapter 2

Decomposing the Domain

Planning the journey: What will be the main stopping places along the way?

Definitions Used in This Chapter

The following definitions are used for the remainder of this chapter. For more detail, and possible alternative definitions see CQRS in Context in the Reference Guide.

Domain

The Domain refers to the business domain for the Contoso Conference Management System (the reference implmentation). The previous chapter The Contoso Conference Management System provides an overview of this domain.

Bounded Context

The term Bounded Context comes from the book "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans. In brief, this concept is introduced 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 autonomous business component defining clear consistency boundaries: one bounded context typically communicates with another bounded context by raising events.

BharathPersona: When you use the CQRS pattern, you often use events to communicate between bounded contexts. There are alternative approaches to integration such as sharing data at the database level.

Context Map

Comment [DRB]: To do - expand this section and add a definition in the Reference Guide.

Bounded Contexts in the Conference Management System

The Orders and Registrations Bounded Context

When a registrant interacts with the system, the system creates an Order to manage the Reservations, payment, and Registrations. An Order contains one of more Order Items.

A Reservation is a temporary reservation of one or more seats at conference. When a registrant begins the ordering process to purchase a number of seats at conference, the system creates Reservations for the number of seats requested by the registrant. These seats are then not available for other registrants to reserve. The Reservations are held for n minutes (n is one of the properties of the conference defined by the Business Customer) during which the registrant can complete the ordering process by making a payment for those seats. If the registrant does not pay for the tickets within n minutes, the system deletes the Reservation and the seats become available to other registrants to reserve.

Comment [DRB]: At the moment the value of _n_ is hardcoded - this may change in the future and become a parameter than can be set by the Business Customer.

The Conference Management Bounded Context

The On-site Client Application Bounded Context

The Payments Bounded Context

The Conference Feedback Bounded Context

The Context Map for the Contoso Conference Management System

Figure 1 and the table that follows it provides a Context Map that shows the relationships between the different bounded contexts that make the complete system and as such it provides a high-level overview of how the system is put together.

BharathPersona: A frequent comment about CQRS projects is the difficulty in understanding how all of the pieces fit together, especially if there is a large number of commands and events in the system. Often, you can perform some static analysis on the code to determine where events and commands are handled, but it is more difficult to automatically determine where they originate. At a high-level, a context map can help to understand the the integration between the different bounded contexts and the events involved. Maintaining up to date documentation about the commands and events can offer a more detailed view. Additionally, if you have tests that use commands as inputs and then check for events, you can examine the tests to understand the expected consequences of particular commands (see the section on testing in Extending and Enhancing the Orders and Registrations Bounded Contexts for an example of this style of test.

Figure 1 shows the six bounded contexts that make up the Contoso Conference Management System. The arrows on the diagram indicate the flow of data as events between them.

Figure 1

Bounded Contexts in the Contoso Conference Management System

The following table lists the events that are associated with each of the numbered arrows.

Integration #Messages
1 ConferenceCreated (Event)
ConferenceUpdated (Event)
ConferencePublished (Event)
ConferenceUnpublished (Event)
SeatCreated (Event)
SeatUpdated (Event)
2 Attendee information - TBD
3 InitiateInvoicePayment (Command sent from Registration MVC controller)
InitiateThirdPartyProcessorPayment (Command sent from Registration MVC controller)
4 PaymentCompleted (Event)
PaymentRejected (Event)
5 GetConferenceDescription (request from client)
??
6 AttendeeCheckedIn (Event)
RegistrationUpdated (Event)
GetConferenceStatus (request from client)
7 RegistrationAddedOrUpdated (Event)
RegistrationRemoved (Event)
AttendeeCheckedIn (Event)
8 ??
9 ??
10 ??

BharathPersona: Some of the events raised from the Conference Management bounded context are coarse-grained and contain multiple fields. Remember that Conference Management is a CRUD-style bounded context and does not raise fine-grained domain-style events.

Why Did We Choose These Bounded Contexts?