Architecture, kept intentionally simple.
A reviewable starting point for the ERP structure, integrations and operations. The repository had no existing application stack, so these are proposals—not implementation commitments.
Confirm franchise isolation, accounting boundary, expected scale, hosting and operational ownership before locking the design.
Proposed system shape
Modular monolith proposal with transactional boundaries in one relational data layer.
Web interface
React browser UI for ERP users, warehouse operators and outlet POS workflows.
Versioned REST API
Node.js candidate service; validates inputs, permissions, scope and workflow state.
Modular ERP core
Procurement, inventory, manufacturing, QC, sales, franchise, finance and HRM.
Relational database
PostgreSQL candidate; transactional records, immutable ledger history and audit.
Architecture principles
Controls that should survive technology and vendor choices.
One auditable stock story
Posted stock movements form the inventory ledger. Balances are derived or reconciled; corrections create referenced adjustments.
Scope every request
Authorization is checked server-side for each action, organization and location—not just by hiding interface controls.
Atomic, retry-safe work
Stock and finance writes use transaction boundaries and idempotency to prevent duplicate effects after retries.
Keep production lineage
Orders retain the exact approved formula version and link consumed raw lots to finished batches and downstream movements.
Recover before scaling
Define backups, restore tests, monitoring and deployment ownership before production use.
No speculative infrastructure
Begin without microservices, brokers or clusters unless measured scale or reliability needs justify their cost.
Decisions to close
These choices affect data boundaries, implementation effort and operational cost.
| Decision | Question | Recommended starting point | Status |
|---|---|---|---|
| DEC-001 | Organization and franchise data boundaries | Explicit row/location scopes; do not presume franchise tenancy | P0 · Open |
| DEC-011 | Accounting system boundary | Choose full accounting, external integration or reports-only before posting design | P0 · Open |
| DEC-023 | Workload and hosting targets | Size using expected users, outlets, batches and transaction volumes | P1 · Open |
| ADR-003 | Application structure and database | Evaluate modular monolith / relational DB against client team and hosting | Proposed |
Not included by default
These introduce meaningful delivery or support overhead.
No independent scaling or operations need has been confirmed.
Needs an explicit synchronization, duplicate protection and conflict-resolution design.
Accounting, payment, government and messaging integrations require separate approval and vendor validation.