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.

Daniel Jalkut said that once you become a parent, it colors everything you do. He was talking about writing his first iOS app, Shush.

But a different thought crossed my mind when talking with my wife about the newest addition to our family. Did she feel like a mother? Did I feel like a father? We both agreed that it came and went. But if we really reflected on our lives, our wedding didn’t make us feel married. That had happened long before. And by inches.

What does being a father feel like to me? I feel most like a father when I roll up my sleeves and do the hard things. When I dealt with the Hospital Finance Department. When I drove home for 4 hours with my newborn in over 100 degree heat. When I change a diaper. When I clean a kitchen full of bottles and fill them with formula. When I do any number of household chores to ensure my wife dosen’t fall in to the trap of doing everything herself and she has time with her daughter.

Before becoming a parent I did some baby sitting. It was great until it wasn’t. Once the fussing began, I had one thought in my head. “I hope the parents get back soon.”

Once it was my kid the thought was different. I knew what it could be and how to solve all of it, except for just random fussy. But I have yet to stress during the fussing. She’s mine. I’m the one to make it all better.

What does this have to do with software? Ever been on a project where things go wrong and you have the thought, “Can I get transferred? Then this would end.” How about when things fall apart and the only thing you think is, “I got this!” Or even, “I don’t know if this project is possible, but I’m going to fly it in to the ground to find out.”

I’ve had all of those thoughts and I don’t think it has to do with whether or not I’m being professional or not. It has to do with Entitlement. By entitlement, I mean the psychological sense of belonging. It is mixed in to a few things, the most important is that your decisions and inputs are impactful both in the short and near term. If your are a clock punching monkey, you don’t love your work. The best you can do is baby sit a failing project.

If you are Entitled, it isn’t a feeling of being a design prima donna telling everyone what to do. Instead, it’s a feeling of being involved in the conversation of creation. It isn’t about being the loudest voice, but of being a voice that is respected and considered. It is then you feel like you are parenting a project. And a project you can parent is a project you can love warts and all. It is a project you will do everything for once it has growing pains.