Skip to content

Development

Layout

  • BinanceOrderBook/ — src/, tests/, config/config.json, scripts/*.py, its own versions.env + CHANGELOG.md.
  • @common/scripts/ — shared deployment tooling (copied from virtufin-execution-engines/@common/scripts, plus a new schedule_trigger.py wrapping the platform's Trigger gRPC service).
  • docs/ — this MkDocs site.
  • versions.env — docs-only pin (API_VERSION=v1; each worker has its own LIBRARY_VERSION, no lockstep across workers).
  • Virtufin.MarketDataEngines.slnx — solution for the C# worker projects.

Build & test

dotnet build Virtufin.MarketDataEngines.slnx
dotnet test Virtufin.MarketDataEngines.slnx

Publishing

Per-worker CI workflow (e.g. .github/workflows/binanceorderbook-nuget.yaml): tests, then dotnet publish (which produces the worker nupkg via the PackageWorker MSBuild target in the worker's own .csproj, not a plain dotnet pack output), then pushes to the Gitea NuGet feed, failing loudly if the version is already published.

Versioning

Each worker directory is versioned independently (its own versions.env + CHANGELOG.md), matching virtufin-execution-engines'/virtufin-strategies' convention.

Conventions

  • Each worker's .csproj carries its own PackageWorker MSBuild target — don't hand-roll packaging differently per worker.
  • Keep a worker's pure logic (state machines, JSON decode/encode) separate from its WorkerBase CloudEvent glue, so the former is unit-testable without any codec/engine machinery.
  • A worker binds explicit topics per instance — never a wildcard. Where a worker's input is deliberately flat/shared, its dispatch logic demultiplexes by payload content, not by topic granularity — document the rationale in the worker's own README when this diverges from the spec's per-pair topic pattern.

See AGENTS.md for the full set of repo-specific conventions.