Product Architecture Pattern¶
This is a pattern, not a mandate¶
This document describes the general architecture pattern most Digital Products products are expected to follow, given that the venture's initial format is Excel. Some future products may not be workbooks at all — a web app, a SaaS product, or a tool built on a different platform would follow a different architecture. When that happens, the relevant product specification should define its own architecture document rather than force-fitting this pattern. See future-platform-strategy.md.
The workbook-centric pattern¶
For an Excel-based product, the architecture is best understood as a data flow with four layers, implemented across the tab structure described in ../standards/workbook-architecture-standard.md:
- Configuration layer — Setup/Configuration tab(s). Centralized settings that parameterize the rest of the workbook (see ../standards/configuration-standard.md).
- Input layer — Primary Inputs and Supporting Inputs tabs. Raw, customer-entered data, validated at the point of entry (see ../standards/input-and-validation-standard.md).
- Calculation layer — Calculations tab(s), possibly hidden but documented. Derives intermediate and final values from configuration and input data, following ../standards/calculation-and-formula-standard.md. Reference Data supports this layer with lookup tables and constants.
- Output layer — Dashboard and Reports tabs. Presents summarized, customer-facing results derived from the calculation layer, following ../standards/dashboard-and-reporting-standard.md.
Data flows in one direction through these layers: configuration and inputs feed calculations, calculations feed outputs. Outputs should never feed back into calculations or inputs in a way that creates circular dependencies a customer can't follow.
An Archive/History layer, where present, sits alongside this flow, capturing snapshots over time rather than participating in the live calculation chain.
Named ranges and structured references as the connective tissue¶
Rather than cross-tab cell references scattered arbitrarily, the architecture relies
on named ranges and Excel Table structured references to connect layers, so that the
data flow is traceable by name (e.g., cfg_DiscountRate, tbl_Inputs[MonthlyIncome])
rather than by opaque cell coordinates. This also makes the architecture more resilient
to row/column insertion during maintenance.
Extensibility¶
This pattern is deliberately compatible with the idea that a product's calculation logic could, in principle, be reimplemented on another platform (see component-architecture.md and future-platform-strategy.md) because the four-layer separation maps onto most structured tools regardless of platform. That said, per the product philosophy, this compatibility is a secondary benefit — it is never used to justify weakening the Excel implementation.