Black Friday is coming soon, so let’s talk about warehouse management and event sourcing.
When developing a system for event retrieval with aggregates, several very different concepts are possible. If you think of an aggregate as a transaction boundary, then each decision has its own implications.
The aggregate can also be a lifecycle boundary - events in a global uniform stream can often only be discarded by the aggregate stem.
In this sense, it is always very interesting when people come up with completely different solutions to the same problem. This is exactly what happened when Christian Folie and I were talking about an event-driven inventory problem.
Warehouse Management Domain
Let’s say we have a warehouse management solution that handles products, locations and sales, linking them together.
In this kata, we focus on locations. Each location is a place where products can be placed. A location can be a shelf, a table, a bin, a box, or one of many other variations.
For the purposes of this kata, we will assume that we are only concerned with box locations for now. These are the cartons that are placed on a picking cart:
Boxes are short-lived:
A customer order comes in.
The warehouse employee starts picking the items for the order. He takes an empty box or bin and creates an ID for it. At this point, we run "AddLocation."
Usually, warehouse workers have a batch picking cart, so they put away a dozen boxes in advance. This way, they can go through the warehouse only once and prepare a dozen orders in one go. So the system creates and prints labels for a dozen boxes at once.
When picking is complete, the boxes are transferred to quality assurance and then shipped. They disappear from the system. In rare cases, if something goes wrong, they can live on for a few more days until the problem is fixed.
API for managing boxes
Let's define an API for the system that can handle site creation in the proto3 specification (why proto3? see below):
