Modeling Exercise: The Grocery Store's Checkout Model

I went to the super market yesterday, and I forgot to get out of work mode, so here is this post. The grocery store checkout model exercise deals with the following scenario. You have a customer that is scanning products in a self-checkout lane, and you need to process the order.

In terms of external environment, you have:

• ProductScanned ( ProductId: string ) event
• Complete Order command
• Products ( Product Id –> Name, Price ) dataset

So far, this is easy. However, you also need to take into account:

• Sales (1+1, 2+1, 5% off for store brands, 10% off for store brands for loyalty card holders).
• Purchase of items by weight (apples, bananas, etc).
• Per customer discount for 5 items.
• Rules such as alcohol can only be purchased after store clerk authorization.
• Purchase limits (can only purchase up to 6 items of the same type, except for specific common products)

The nice thing about such an exercise is that it forces you to see how many things you have to juggle for such a seemingly simple scenario.

A result of this would be to see how you would handle relatively complex rules. Given the number of rules we already have, it should be obvious that there are going to be more, and that they are going to be changing on a fairly frequent basis. A better model would be to actually do this over time. So you start with just getting the first part, then you start streaming the other requirements, but what you actually see is the changes in the code over time. So each new requirement causes you to make modifications and accommodate the new behavior.

The end result might be a Git repository that allows you to see the full approach that was used and how it changed over time. Ideally, you should see a lot of churn in the beginning, but then you’ll have a lot less work to do as your architecture settles down.