The generator factory and the kind seam
Table of Contents
1. Summary
The generator factory, in ores.marketdata.synthetic.api, maps a kind string to
the builder that constructs a generator from persisted configuration. The runner
and the control plane request a generator by kind and never name a concrete class.
That one lookup is the seam.
2. Detail
2.1. The lookup
make(kind, ctx, input) finds the builder registered for kind, calls it with the
shared context and the build input, and returns the generator as a
std::shared_ptr<i_generator>. It throws std::invalid_argument when the kind has
no builder, and when the input is not the kind's own member. register_kind
replaces a builder. kinds() returns the sorted kind strings.
make_default_generator_factory() registers fx_spot and ir_curve.
2.2. Why the input is a variant
generator_build_input is a std::variant with one struct for each kind. Each
struct holds the persisted config and the child rows that the kind needs. The IR
input also holds a resolved refdata context. The variant lets one make
signature serve every kind and puts the input check inside make.
2.3. The context
generator_build_context holds the raw NATS client and the service client. The
client reads the fixings a feed starts from in the market data service, as the
system. See
The identity an adapter runs as.
2.4. The registry beside the factory
Construction is one of the things a kind needs. The config read permission, the
config rows, the loader, the calibration inputs and the simulate payload also vary by
kind. generator_kind_registry holds them. A registration there refuses a kind the
factory cannot build, so the two cannot drift.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- Adding an asset class — completes: the edits a new kind needs.
- The synthetic runner — completes: the caller of the factory.