2026-06-29 09:04:56 +00:00
parent e3929d6b99
commit a37d4566ba
1 changed files with 31 additions and 0 deletions
@@ -0,0 +1,31 @@
# NextGen Product Model
## Motivation
The product model in eStack is one of the oldest bits of code in the system.  It's showing its age, and is often the source of friction.  Unfortunately, it's also pretty central, so lots of other code depends on it.  This document is meant to explore what a v2.0 data model for products (and combos) might look like.
## Model Scope
To be clear, the Product Model, as discussed here, is pretty narrowly bounded.  It is concerned only with modelling products themselves, and is not concerned with stock-levels, inventory-locations, costs, prices, nor offers (listings).  Modules concerned with those areas will clearly **depend** on the Product Model, but that dependency should be unidirectional.  That is, the product-model module should be entirely ignorant of those modules and their concerns, even though it's specifically designed to be **used** by those modules.
## Important Dimensions
There are several areas of concern which prompted me to begin writing on this subject.  In particular, the current eStack product/combo model exhibits certain shortcomings that we'd like to overcome.  Separately, there are certain potential future use-cases that the current model won't support well, and which should be considered in a redesign.
### Current system is highly-coupled to six-digit, numeric, SKUs.
This comes up in lots of places in the system, and needs to change.  SKU format limitations should be minimal by default.  The only constraints should be uniqueness and potentially a maximum length.
### Kitted Products (combos) create unnecessary complexity.
This is the "big one".  A new system should be judged on how easy it is to reason about, while also potentially be much more flexible to support things like "nested combos", a distinction between make-to-stock and make-to-order, and removal/refactoring of branching logic when dealing with single-item products vs combos.
### SKU-Range functionality is too tightly coupled to products.
My feeling is that the feature should be removed, and possibly re-introduced as a separate helper-module if desired.  The current implementation is somewhat brittle, and really only works for numeric-only SKUs.
## Product Module Entities
"Product" can mean different things, often subtly, depending on context.  For example, in a purchasing context, we're typically dealing with discrete components ordered from a vendor.  It's probably safe to assume that purchased items will never be decomposed into constituent parts, since that would create significant challenges with cost-tracking.  Alternatively, in a sales-order context, a "product" might represent a collection of individual items.  Furthermore, that collection might be made-to-order (assembled at picking-time with no intermediate work order), or made-to-stock (components assembled from parts and then tracked as a single unit).  The latter process isn't one we've really considered yet, but it is a feature typically found in similar systems, which implies that it's a common business requirement in the market.