This repository is the FINOS TraderX sample trading application. It is intentionally simple, non-production, and designed for local experimentation across a distributed set of services.
README.mdfor overall purpose and run modes.docs/running.mdfor default ports, startup sequences, and environment variables.docs/README.md,docs/overview.md, anddocs/flows.mdfor architecture and sequence flows.docs/c4/workspace.dslfor the C4 diagram source (use Structurizr Lite to render).
database/(H2 database)reference-data/(Node/NestJS reference data)trade-feed/(Node/Socket.IO pub-sub)people-service/(.NET)account-service/(Java/Spring Boot)position-service/(Java/Spring Boot)trade-service/(Java/Spring Boot)trade-processor/(Java/Spring Boot)web-front-end/(Angular + React clients)docs/andwebsite/(documentation site)gitops/andingress/(K8s/Tilt and ingress config)
- Docker Compose (full system): from repo root,
docker compose up(seeREADME.md). - Kubernetes/Tilt: see
gitops/local/Tiltfileanddocs/running.mdfortilt up. - Manual run: see
docs/running.mdfor the recommended startup sequence and port env vars.
- Each service has a
README.mdwith run details and prerequisites. Read that before editing. - OpenAPI specs are generated at runtime (Swagger) and saved as
*/openapi.jsonwhen you runscripts/generate-openapi.sh. Swagger UI is typically exposed at/swagger-ui.html(or service-specific Swagger routes). - Java services use Gradle wrapper (
./gradlew) from their service directory. - Node services use their local
package.jsonscripts. web-front-end/contains both Angular and React implementations; check each subfolder's README.
- Prefer small, targeted edits in the service you are touching; do not refactor cross-service behavior unless requested.
- If behavior or APIs change, refresh the OpenAPI specs via
scripts/generate-openapi.shand update any relevant docs indocs/. - Keep the non-production, demo nature of the project in mind.
When adding, removing, or changing services or their interactions, update all relevant diagrams:
- C4 diagram (
docs/c4/workspace.dsl) - The Structurizr DSL is the source of truth for architecture. PNG images are auto-rendered by GitHub Actions on push. - Mermaid diagrams in
docs/overview.md(simplified architecture) anddocs/flows.md(sequence diagrams). - Component table in
README.mdif adding/removing services.
The C4 DSL and Mermaid diagrams should stay consistent—if you update one, check if the other needs the same change.
The project has two content surfaces that may overlap:
docs/- Markdown files served by Docusaurus (architecture, flows, running instructions)website/src/components/- React components for the landing page (feature highlights, intro text)
Avoid duplication: The landing page is marketing-style (logo, tagline, feature cards, CTAs). The docs/ folder is the reference material. If you add content, decide which surface it belongs to—don't put the same text in both places.
Project history: When making major changes (new services, architectural shifts, significant features), add an entry to docs/project-history.md. Minor fixes and routine maintenance do not need to be recorded.
Relative links in docs: Links like ../account-service work on GitHub. The Docusaurus remark plugin (website/src/remark/transformRelativeLinks.js) converts them to full GitHub URLs at build time. Keep using relative links in docs/ markdown files.
- Architecture/flows:
docs/overview.md,docs/flows.md,docs/c4/workspace.dsl - Local run and ports:
docs/running.md - Docker/K8s:
docker-compose.yml,gitops/local/Tiltfile - Front-end:
web-front-end/angular/README.md,web-front-end/react/README.md - Docs site:
website/README.md,docs/