One of the important concepts in architecture is where to draw the lines in your software. What parts are relevant to what actions and what users? Bounded Context is a way of handling this mismatch.
Basically, it means that similar abstractions can get transformed on one side of a system boundary or another. It’s perfectly okay for these similar items to have very different fidelity and behaviors. After all, they may be similar things, but they are very different. Confusing an entity’s different data and roles in different contexts just adds more complexity.
Example 1 – Dinner
Let’s say my wife and I go to dinner with a friend we will call Jed. Jed orders a taco platter, a margarita, and the flan. I order 3 enchiladas, substitute refried beans for the spinach casserole, and a Diet Coke. My wife gets a taco and enchilada and just has water.
The server sends our order back to the kitchen. Once the food is finished, one of the waitstaff will bring the plates to our table, using seat numbers to pick who gets what at the table.
Once we are done, our server splits our ticket in to Jed’s bill and Mine. At this time, we don’t care about what seat number had what food, but only that Jed gets charged with the Flan, and I get charged with the Diet Coke. Jed pays with cash. I give our server my card.
Once my server returns with the receipt, I add a tip and sign.
Finally, my server reports the tip to the credit card company.
There are Four contexts in which the receipt is used.
- Plates for the kitchen to fulfill
- Plates and Seats for delivery
- Itemized receipt for verification by payer
- The unitemized credit card receipt
Are these receipts the same? Nope, buy they all map to the same seating. In modeling the system in software it may greatly simplify our code to model each of these contexts as isolated subsystems. Then when we hand a receipt from one subsystem to another, we translate to a specific model of what is a receipt.
Example 2 – Project Billing
Our company’s time is tracked using our bespoke time tool. We log each entry to the quarter hour and to a task code for a project. We also track what task item on which we were working at the time.
When it comes time to bill our customers, we roll each entry’s duration in to a bill. Oh, and the tasks may map 1-to-many task to Purchase order. And yes, a project can have several purchase orders that may or may not be used in parallel.
In the billing system, we don’t care about what hours were worked, but how many. In the time tool, what hours worked makes it easier for us to report our time.
When it’s time to generate our invoices, we translate from one bounded context in to a form useful for another bounded context. Especially since we don’t have complete control over our billing system since it is developed by a vendor.
The dinner example could be handled with using ‘views’ of an entity’s data. On the other hand, our billing example would definitely be made more difficult if we let our billing vendor define our time tool’s model. It’s a tool in the tool box, but it’s still not a golden hammer.