Search code examples
architecturecqrsevent-sourcinginventoryinventory-management

Inventory Counts with Event Sourcing


I am trying to rewrite a CRUD based inventory system using event sourcing/CQRS.

The problem I am having is with how to deal with inventory counts. The idea is a store will occasionally want to count their inventory and determine if there is any shrink (either items we thought were sold but are still in inventory, or items we thought were in inventory but cannot be located in the store).

In the CRUD system when someone starts a count , the system creates a list of all available inventory in a table called "expectations" and as each inventory item is scanned, it basically marks that item off the expectations list. The shrink is the difference is anything in the expectations list which was not scanned, or anything scanned that was not in the expectations list.

The problem is I cannot understand how to represent this in ES. If my only entity is "inventory" how do I determine when a count has been started or completed?

Even any examples of ES/CQRS inventory systems I Could look at would be helpful

Any help greatly appreciated.


Solution

  • In the CRUD system when someone starts...

    The word "start" is a big hint here - it suggests a process that will have its own bookkeeping to do.

    The other thing to notice is that -- aside from the domain model's idea of what inventory "should" be present -- pretty much all of the data comes from the real world. Some human being decides when the audit should start, when the audit ends, which pieces of inventory are accounted for.

    In an event sourced world, you should expect this process to have its own stream of events - a burst of events at the beginning to register which pieces of inventory you need to account for, and then additional events as the disposition of the inventory becomes clear.

    Notice that the data is a copy of the inventory; just in the same way that the current process copies the stuff you want into a new table to work on. That turns out to be really important when concerns like autonomy show up.

    (it may also be a digest -- there may be fields on the inventory table that you don't value when performing the expectations audit.)

    So you are saying it is OK to have aggregateroots that do not represent a real "thing"

    Yes, although the more useful idea is that instances of business processes are a real thing.

    If you like, think of the journal/log/document that keeps track of the work being done as the "thing".