# 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
```