Product and Pricer Registry
Use registries to map product types and models to pricers instead of hard-wiring dependencies.
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.
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.
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”.