Files
trade-doc/gitea-tree.md

144 lines
3.7 KiB
Markdown

# Gitea Tree
To drzewo rozdziela:
- `repo kodowe`: gdzie utrzymywany jest kod danego bloku
- `repo deployowe`: gdzie utrzymywane sa manifesty uruchomieniowe
## Drzewo
```text
trade-frontend.git
├─ trade-frontend
├─ trade-api
├─ momentum-service
└─ bot-observer
trade-drift-dlob.git
├─ dlob-publisher-hot
├─ dlob-publisher-all
├─ dlob-hot-redis-to-postgres-raw-writer
├─ dlob-hot-postgres-to-postgres-derived-writer
└─ dlob-all-redis-to-postgres-derived-writer
trade-deploy.git
├─ deploy trade-frontend
├─ deploy trade-api
├─ deploy dlob-publisher-hot
├─ deploy dlob-publisher-all
├─ deploy dlob-hot-redis-to-postgres-raw-writer
├─ deploy dlob-hot-postgres-to-postgres-derived-writer
├─ deploy dlob-all-redis-to-postgres-derived-writer
├─ dlob-redis
├─ postgres
└─ hasura
trade-iac.git
└─ host / infra provisioning
```
## Uwaga
- `deploy` nie oznacza osobnego kodu biznesowego. Oznacza warstwe uruchomienia: `k8s`, `kustomize`, `ArgoCD`, `env`, `secrets`, `resources`, `probes`.
- Jeden blok moze miec osobno `repo kodowe` i osobno `repo deployowe`.
- Dla aktywnego stacku DLOB kod siedzi glownie w `trade-drift-dlob.git`, a uruchomienie w `trade-deploy.git`.
## Czy robic repo per bloczek
Nie jako domyslny kierunek.
Lepszy jest podzial `repo per domena/runtime` niz `repo per deployment`.
Powody:
- repo per bloczek szybko duplikuje typy, helpery, CI i releasy
- publishery i writery DLOB sa ze soba mocno sprzezone
- wiele zmian przechodzi przez kilka blokow naraz
- koszt synchronizacji wielu malych repo zwykle przewaza zysk
Dla obecnego ukladu sensowny podzial to:
- `trade-drift-dlob.git` dla warstwy market data / DLOB runtime
- `trade-frontend.git` dla UI i lekkich uslug aplikacyjnych
- `trade-deploy.git` dla uruchomienia w klastrze
- `trade-iac.git` dla hosta i infrastruktury
## Proponowany Podzial: trade-bot.git
Jesli wydzielac bota do osobnego repo, to tylko warstwe bot logic / strategy / execution.
Naturalni kandydaci:
- `bot-observer`
- `momentum-service`
- przyszly executor
- future control-plane / config-state adaptery
Tego nie warto pakowac do repo bota:
- `dlob-publisher-hot`
- `dlob-publisher-all`
- writery DLOB
- `postgres`
- `hasura`
- runtime `dlob-redis`
To jest wspolny data plane, a nie logika jednego bota.
## Rola trade-deploy i trade-iac
Po wydzieleniu bota uklad powinien byc taki:
- `trade-bot.git`
kod bota: observer, momentum, strategy, executor, adaptery
- `trade-deploy.git`
manifesty uruchomieniowe: `Deployment`, `CronJob`, `Secret` refs, `env`, `resources`, `rollout`
- `trade-iac.git`
infrastruktura nizszego poziomu: hosty, provisioning, `k3s` bootstrap, storage, DNS, certy, siec
Praktyczny podzial odpowiedzialnosci:
- `trade-iac` = jak istnieje srodowisko
- `trade-deploy` = co jest wdrozone na srodowisku
- `trade-bot` = co robi bot
## Docelowe Drzewo
```text
trade-frontend.git
├─ trade-frontend
└─ trade-api
trade-drift-dlob.git
├─ dlob-publisher-hot
├─ dlob-publisher-all
├─ dlob-hot-redis-to-postgres-raw-writer
├─ dlob-hot-postgres-to-postgres-derived-writer
└─ dlob-all-redis-to-postgres-derived-writer
trade-bot.git
├─ bot-observer
├─ momentum-service
├─ strategy
├─ executor
└─ bot control-plane
trade-deploy.git
├─ deploy trade-frontend
├─ deploy trade-api
├─ deploy trade-bot
├─ deploy dlob-publisher-hot
├─ deploy dlob-publisher-all
├─ deploy dlob-hot-redis-to-postgres-raw-writer
├─ deploy dlob-hot-postgres-to-postgres-derived-writer
├─ deploy dlob-all-redis-to-postgres-derived-writer
├─ dlob-redis
├─ postgres
└─ hasura
trade-iac.git
└─ host / infra provisioning
```