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.

1. Plates for the kitchen to fulfill
2. Plates and Seats for delivery
3. Itemized receipt for verification by payer
4. 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.

Final Thoughts

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.

In the near future I’m going to use a word. I’m going to use it as a cornerstone of an argument for something a bit radical. Not very, but a bit. The word is Use Case. Since everyone has an opinion, I’m going to be specific about what I mean.

Use Cases were invented by Ivar Jacobson in the 1980’s as a way to solicit requirements. It is NOT a way to use spare day-old boxes, arrows, and lollipops. While UML has a thing called Use Cases, that ain’t it. I mean a list of actor/system interactions with some context and some deviations. What do I want to use it for? It gives me, a developer, a fuller idea of what I’m actually supposed to build for my customer.

As close as I usually get is, after a conversation with a customer or team lead, is a bulleted list of things to do. It looks a bit like this:

• Add an activity to my time sheet.
• Set a start and end time to the activity.
• Describe the activity.
• You can’t save the activity if it doesn’t have a description or time range.
• Choose a time code associated with the activity. There should be a default.
• Display the activity on the time sheet.

It is generally how I think I’m going to implement the feature in enough detail to get all the corner cases implemented. This is not a Use Case, it’s a todo list. It doesn’t share any information about workflow or context or motivation. In short, I’m left with no empathy for my users. And if I don’t have empathy for my users, how can I try to make their lives, or at least their experience using my software, better?

A Use Case as I want to use term focuses on workflow and on the context surrounding the actions being described. It has the following parts:

• Title A name to distinguish it from other Use Cases
• User Intention Describes who, why, and what
• Precondition Where in the system your interaction will take place
• Interactions The happy path
• Extensions How conditions cause the happy path to deviate
• Postconditions How I expect those interactions to impact the system

Most of these are just prose, the interactions and extensions are tables with two columns, the actor’s actions and the system’s response. Each row is numbered. The Interaction rows are simple numbers. The extensions are numbered with numbers and letters to relate to the interaction they modify.

Great! I’ve created a wonky definition! Now what the heck does that look like?

An example

Add an Activity to a Time Sheet

Tony logs time spent working on the Bryce Co project so Cheryl can bill against the Bryce Co account.

Precondition User is logged in and viewing an editable timesheet

Interactions

Extensions

User enters none or only one of the start and end time