Recipe vs. Cake — An archetype of Bounded Contexts

I’ve once worked for the IT department of a large restaurant network. They had a secret sauce, and this wasn’t one you could eat.

In a restaurant kitchen, when a customer orders a dish on the menu you have to cook it. You take the recipe with a list of ingredients and their quantities, and you prepare the dish by following the instructions. In theory, if the recipe says you need a quarter of a lemon, then you should be able to cook 4 dishes with one lemon. Unfortunately, when you analyze the actual consumption of ingredients over a day, you realize that in practice you actually made 20 dishes with 6 lemons. That’s 3.3 dish by lemon! Life is not as nice as theory, in real life you have waste and failures. A quarter of lemon falls on the floor and you can’t use it. A lemon was too small so you has to use a “bigger quarter”, and there are only 3 bigger quarters in one lemon. And the last lemon that was used could not be used completely because the number of dishes actually ordered is not a multiple of 4.

The restaurants network I’ve worked for were very good at analytical accounting. This was their secret sauce. They were actually monitoring the usage of lemons, among other things. That was key to their profitability, because businesses like restaurants have quite narrow margins. It was important for them to know better the gap between the recipe and the actual cooking of the dishes.

It happens that tracking the gaps between what was planned — the recipe, and what is actually built — the cake, is important for lots of businesses in all domains.

In manufacturing, you have a bill of material, the BOM, that is necessary to build a product. The BOM states that you need 12 screws to close the enclosing. However in practice you may lose one screw and end up consuming 13, not 12. If the tracking report shows this situation happens often and if the screws are expensive enough, then some engineers will want to improve something on the production line to prevent that. You may automate, or make the screwdrivers magnetic.

In hardware electronic manufacturing you build silicon waffles that will make thousands of chips. This is the theory, before the quality control where you discover how many of them are dysfunctional. This kind of manufacturing is expensive, so you want to monitor that.

Mature businesses have lots of competitors, and they often compete on continuous optimizations of the delivery process. You need tracking for that. That’s a recurring business problem, and you need software for that.

In such situation you most likely have two distinct Bounded Contexts: one for describing the plan, and another for tracking the gaps between what actually happens and the plan. Even if the two contexts seem to deal with the same real-life concepts, they have in fact many reasons not to be rely on the same software model.

The one context approach

At first, “the recipe from the book” and “the recipe as I’ve actually done it” (aka a cake) look just the same thing. That’s why a common approach is to mix both models into one. I think this is a poor hack.

For example project management tools like MS Project focus on the theoretical plan, and then they add extra fields to track the time actually burnt directly on the elements of the plan. It may work as long as it’s very simple. The more we move forward into complexity, the more it won’t make sense to keep the two models aligned. With a TODO list, “Done!” might be enough, but as the tracking becomes more complex, it will grow its own tracking domain.

Different intentions

Modeling the recipe and the tracking of the actual cooking of the cake look similar, but they are totally different in their intentions. The recipe aims at telling how to prepare the dish, including instructions on how to stir or how to cut the vegetables. The tracking focuses on waste, errors, or improving the purchase process or the supply chain management. That’s a strong reason to call for a different point of view.

Other differences

Limited Observability

For tracking you may not be able to observe all details. The recipe talks about quarters of lemon, but a quarter of a lemon does not exist on the market. You can only measure the number of lemons you bought, and the number of remaining lemons at the end of the day.

Unexpected Events

What actually happens during cooking, during a manufacturing process or during a project can be totally different from the plan. Perhaps there was no more lemon, so the cook had to exceptionally replace with some lemon juice, an ingredient that is not even in the recipe. A good tracking model should accommodate the tracking of this kind of event.

Low-Frequency

On a similar note, for steering purposes, a coarse level of granularity is often enough. You can neglect details from the process. Perhaps a weekly or monthly inventory of the remaining ingredients is enough. Tracking the actual consumption of ingredients dish by dish would be a total waste of time!

Modeling

Modeling the plan, the bill of material, the manufacturing steps etc. is not the challenging part of the Actual vs Plan Gap Tracking relationship.

Typically the tracking context needs its own distinct model, a totally different one than the planning model. For tracking cargos shipment, for example, you’d probably track loading and unloading events at various ports. The tracking model would be a journal of events. For tracking the consumption of materials, the tracking model would be a time-stamped snapshot of the current inventory.

A good model to plan an itinerary is about legs or segments, whereas a good model for tracking the cargos is probably about events.

The tracking model may link to the plan. This case is a bit like the Knowledge Level pattern (Fowler): the plan is the Knowledge Level, and the tracking of the actual production would be the Operation Level. Here the knowledge Level defines the ideal case, but the actual behavior at the operation level will regularly diverge from the ideal, because this discrepancy is indeed what we want to track.

The tracking can also live in its own bubble, with no link to the plan. If that’s the case, a separate reconciliation mechanism will do the comparison to highlight the gaps.

A developer example

As usual, as developers we are already familiar with this actual vs plan dichotomy: it’s just called testing.

A test defines the plan, with the expected value or the expected behavior on a mock. A test also observes the actual result of the code and tracks all gaps between them in the test results report. The model of the plan and the model of tracking the actual results are different, and use a totally different language.

In this area, simulation testing also uses a reconciliation mechanism a posteriori to track the discrepancies.

Another example is simply software project planning and tracking. With software projects we know very well that forcing a match between plan and execution is a really dumb idea.

Conclusion

This archetype suggests splitting into two distinct contexts. Avoid the trap of mixing both contexts, unless it is a deliberate and conscious decision. Usually recognizing the two contexts will lead to the conclusion that distinct models are needed, and this will make everything simpler.

Many thanks to @ziobrando and @mathiasverraes for the early feedback and some complements incorporated into the text.

Originally published at cyrille.martraire.com on November 21, 2014.