Let’s imagine a company with about 100 of types of entities and custom software.
Imagine this company purchases “items”, recombines them and “sells the bundles”.
They plan to “try” strapi and move with the “product” area and they will have entities like:
- Products (raw material we purchase to providers: ie: Pack of 1000 pens. Pack of 1000 notebooks)
- ProductManagers (employees responsible of selecting the products to purchase)
- TariffTables (specific to purchase our raw material)
- CargoModes (if the freight comes via container or truck or whatever)
- Countries (where the frieght comes from)
Once setup, internal applications oriented to the purchasing department will move to consume the Strapi API while other internal applications will still be custom-code.
If the thing goes well, they will apply this to marketing and sales with entities like:
- Products (bundled things we sell: Ie: Scholar kit with 3 pens and 2 notebooks)
- ProductManagers (employees responsible of creating the bundles)
- TariffTables (specific to selling our bundles)
- CargoModes (if the bundles are delivered by truck or train)
- Countries (where the bundles must be sent to)
The idea then is to move the applications oriented to the sales people into new UX consuming the Strapi API.
The company does not want to move “all” because it’s too much complexity and prefers to do “one thing at a time”. Therefore thing about purchases without thinking in sales
But once you are done and do the second round… there is a lot of collision in the names.
This is one typical example of DDD and hex-architecture where “Purchasing” is a model and “Selling” is a different model. And one domain model should not depend on another.
But if names conflict… we have a problem.
Does Stripe allow separating classes/entites/definitions into “different namespaces”?
Buy/Products vs Sell/Products
Buy/ProductManagers vs Buy/ProductManagers
so each is an “independent” entity.