Architecture & Systems
Product and Pricer Registry
Use registries to map product types and models to pricers instead of hard-wiring dependencies.
Mental model
A registry makes product-to-pricer selection explicit instead of scattering type decisions through the codebase.
A product registry maps product_type identifiers from booking to concrete instrument classes.
A pricer registry maps (product_type, model_type, purpose) pairs to concrete pricer implementations.
Explore the mechanism
How can the system select a valid pricer for a product and model without embedding type checks throughout the code?
This diagram compares a hard-wired product–pricer mapping with a registry-based design. Use the controls to change how many product types, models, and purposes you support and see how registries cut down direct dependencies.
Without registries, every new product must know about every pricer implementation. Coupling grows as products × models × purposes, and small changes propagate across the codebase.
With registries, booking talks to a product registry and risk systems talk to a pricer registry. New products and models are added by registering them rather than editing core pricing logic. The practitioner’s rule: registries turn “add one product, edit ten modules” into “add one product, register it once”.
What to notice
Registries allow new products and methods to be added without modifying existing pricing code paths.
This pattern enforces dependency inversion: high-level modules depend on interfaces, not on concrete classes.
Where it appears
- dispatching trades to valuation engines
- registering new products and models
- validating supported product-model combinations
Where the intuition breaks
What this view leaves out
- A registry centralizes selection but can become hidden global state unless entries, precedence, lifecycle, and failure behavior are explicit.
Where this concept sits
Follow the strongest prerequisites, applications, extensions, and contrasts.
Connections for Product and Pricer Registry
A product–pricer registry operationalises the separation between instrument definitions and pricing implementations.
SupportsLibrary Release VersioningRegistry changes are part of the public behaviour of a pricing library and should be versioned.
A product–pricer registry operationalises the separation between instrument definitions and pricing implementations.
Explore concept →