How to model/project continous data (warehouse stock over time etc.)?

[urbanhusky]

Hi,

This question has been bothering me for a while now. Assume a DDD/CQRS/ES architecture.
The user needs to be able to determine when the stock in the warehouse is running low so that they can plan purchase orders and productions. This planning is done days, even weeks or months ahead of time and might be subject to constant changes and improvements.
There are thousands of different items to track over multiple warehouses.

I assume that this "planning" bounded context will receive events from other contexts that determine the projected demand on the items and changes in stock level.
I would expect stock level changes to happen only in the past, but that is not a safe guarantee (if it makes sense from a business perspective to have manipulations of the warehouse in the past - I would argue that any manipulations should usually be done "now" when they are detected/made). Planned purchases and productions can be mostly handled by my own BC.

In order to inform the users about projected shortages, we need to be able to track and estimate the stock progression over time. This is also how the user might perceive the forecast demand and stock level - as a graph.
So my read model is centred around each article (sorted by articles that are running low on stock first) and must start from the current (or past few day's) stock level and project over a granular enough sample rate (every few hours?). Determining sub-sample shortages might be hard and not worth the effort (we keep a large enough buffer of stocked items - however if we can keep this low enough, we could gain more benefits) so I wouldn't focus on that right now (unless someone has a solution that doesn't focus on discrete samples).

How could I design such a read model for such a graph and how would the projections from the event stream alter it?
We also face the issue of migrating and coexisting with existing data so we might have an initial stock level of date X and further changes to it afterwards (booking list). We're a strangler application, doing event interception and asset capture.

Our read model store is most likely going to be a RDBMS, but I wouldn't rule out a document database (ravendb).

Regards,
urbanhusky

[@yreynhout]

Might CEP and stream processing in general not be more applicable here? Also note that there's a lot of prior art (and products) around stock and forecasting - surely you don't want me to google that for you? A buy vs build decision is a real option IMO.

[urbanhusky]

CEP/steam processing is a very broad topic. Do you have any pointers as to what I should look for or into? Any reading recommendations?
Buy is most likely out of the question. This is going to be a small part in a much larger system.

[Christian Droulers]

I agree with @yreynhout.

Stock and forecasting seems like something that could be bought. Even if you don't buy, the problem itself doesn't seem like one related to DDD itself. It's a domain problem that needs to be solved on its own (with analysis, projections, maths, etc.) before you can write code. Then, once you figure out *what* you need for forecasting, you can easily build a read-model for it from your events and iterate on your solution.

[urbanhusky]

It's more of a CQRS/ES issue.
This will most likely be solved via a projection that generates documents for each item that represent the forecast demand and change in inventory. These are just a few sample points (between "today" and some brief projection into the future) and there is only one such document for each item.

So any time an event is processed, which causes changes in demand for a specific item, we can just update that document. If there are no such events and we pass the last data point in this document/graph, then the stock level remains constant.