v0.0.3-pre.008
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Inventaire initial des composants KSP
|
||||
|
||||
@@ -9,7 +9,7 @@ Ce document constitue le premier inventaire architectural de `0.0.3-pre.002`.
|
||||
|
||||
Il répond principalement à la question : **quel composant possède quelle responsabilité ?**
|
||||
|
||||
Le premier inventaire a été produit en `0.0.3-pre.002`. `pre.003` l'a corrigé à partir du graphe, puis `pre.004` a détaillé Wire/Program dans [`006-WIRE_AND_PROGRAM.md`](006-WIRE_AND_PROGRAM.md), `pre.005` Execution/Policy, `pre.006` les niveaux durables/Materialization/Store dans [`008-DATA_MATERIALIZATION_AND_STORE.md`](008-DATA_MATERIALIZATION_AND_STORE.md), puis `pre.007` l'exploitation workers/jobs/pipelines dans [`009-ACQUISITION_WORKERS_AND_JOBS.md`](009-ACQUISITION_WORKERS_AND_JOBS.md). Les détails de types Rust restent révisables avec les premières implémentations.
|
||||
Le premier inventaire a été produit en `0.0.3-pre.002`. `pre.003` l'a corrigé à partir du graphe, puis `pre.004` a détaillé Wire/Program dans [`006-WIRE_AND_PROGRAM.md`](006-WIRE_AND_PROGRAM.md), `pre.005` Execution/Policy, `pre.006` les niveaux durables/Materialization/Store, `pre.007` l'exploitation workers/jobs/pipelines, puis `pre.008` Apps/Services/Scenarios/Control dans [`010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`](010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md). Les détails de types Rust restent révisables avec les premières implémentations.
|
||||
|
||||
## Statuts
|
||||
|
||||
@@ -40,7 +40,7 @@ Le premier inventaire a été produit en `0.0.3-pre.002`. `pre.003` l'a corrigé
|
||||
| Store API | `ksp-store-api` | API | N3 contrat | Retenu | `0.3.x` | contrats backend-agnostic, modèles persistants et notifications de données persistées |
|
||||
| Store impl. | `ksp-store-lib` | lib | N3 | Retenu | `0.3.x` | PostgreSQL de référence, migrations, repositories, queries, backlog/replay et notification backend |
|
||||
| Worker lifecycle | `ksp-worker-api` | API | N3 contrat | Retenu | `0.3.x` | lifecycle commun des services continus |
|
||||
| Worker control | `ksp-worker-control-lib` | lib | N3 | Retenu | `0.3.x+` | gouvernance réutilisable des workers pour managers/apps/orchestrateur |
|
||||
| Worker control | `ksp-worker-control-lib` | lib | N3 | Retenu | `0.3.x+` | gouvernance réutilisable de services workers autonomes pour apps spécialisées puis futurs managers/orchestrateurs |
|
||||
| Live raw acquisition | `ksp-worker-raw-retriever` | worker | N4 | Retenu | `0.3.x` | acquisition live/quasi-live -> raw persisté -> notification data |
|
||||
| Raw -> Core | `ksp-worker-core-processor` | worker | N4 | Futur retenu | `0.6.x` | transformer le raw persisté en Core canonique |
|
||||
| Core -> generic mat. | `ksp-worker-generic-materializer` | worker | N4 | Futur retenu | `0.6.x` | produire la matérialisation/journal générique depuis le Core |
|
||||
@@ -171,6 +171,22 @@ Elle doit pouvoir être consommée par :
|
||||
|
||||
Les applications restent des interfaces et ne réimplémentent pas elles-mêmes registre, dispatch start/stop, agrégation d'état ou reconfiguration générique.
|
||||
|
||||
### Packaging des workers
|
||||
|
||||
Chaque package `ksp-worker-<role>` doit pouvoir fournir :
|
||||
|
||||
```text
|
||||
library target
|
||||
-> logique/runtime service réutilisable
|
||||
|
||||
binary target
|
||||
-> bootstrap autonome mince
|
||||
```
|
||||
|
||||
Cette direction permet de tester/réutiliser la logique sans perdre la propriété « service indépendant ».
|
||||
|
||||
Le binaire autonome n'est pas une seconde implémentation du worker.
|
||||
|
||||
### Workers de processing
|
||||
|
||||
Le modèle initial d'un unique W2 est remplacé par une chaîne de responsabilités plus étroites :
|
||||
@@ -239,7 +255,7 @@ ksp-scenario-spm-lib
|
||||
...
|
||||
```
|
||||
|
||||
`ksp-scenario-api` n'est pas retenu actuellement. Une **norme de structure/comportement** commune est préférée à un trait Rust susceptible de limiter des scénarios dont les besoins sont différents. Cette décision pourra être revue si les premières implémentations montrent un vrai contrat commun utile.
|
||||
`ksp-scenario-api` n'est pas retenu actuellement. La norme commune est documentée dans `docs/rules/SCENARIO_CONVENTION.md` et peut évoluer avec les premières implémentations.
|
||||
|
||||
Les applications de démonstration correspondantes suivent la forme :
|
||||
|
||||
@@ -255,7 +271,19 @@ ksp-app-scenario-token-2022-devnet-desk-demo
|
||||
ksp-app-scenario-metadata-devnet-desk-demo
|
||||
```
|
||||
|
||||
Chaque application appelle la crate `ksp-scenario-<domain>-lib` correspondante et ne duplique pas son scénario.
|
||||
Chaque application appelle la crate `ksp-scenario-<domain>-lib` correspondante et ne duplique pas son scénario. La crate scenario doit également pouvoir être appelée hors desktop.
|
||||
|
||||
## Applications spécialisées et control plane
|
||||
|
||||
Les applications spécialisées sont prioritaires sur une future application globale.
|
||||
|
||||
Une app worker spécialisée passe par `ksp-worker-control-lib` / `ksp-worker-api` et ne manipule pas directement l'état interne du worker dans le Store.
|
||||
|
||||
Le data plane est D1–D4. Le control plane porte start/stop/status/health/reconfigure et reste séparé des payloads de processing.
|
||||
|
||||
Les workers doivent être exploitables comme services autonomes. Le mécanisme IPC exact reste à définir à la première implémentation manager/service ; aucun `ksp-ipc-api` générique n'est créé maintenant.
|
||||
|
||||
Une future application globale est conservée dans `docs/IDEAS.md` seulement.
|
||||
|
||||
## Pipelines
|
||||
|
||||
@@ -311,4 +339,5 @@ Le graphe confirme les principes suivants :
|
||||
- `pre.004` : types publics précis de `ksp-program-api` et policy ;
|
||||
- `pre.005` : types publics de transport on-chain et conversion vers les DTO raw de `ksp-store-api` ;
|
||||
- `pre.005` : modèles materializer/store, notifications, replay et provenance ;
|
||||
- `pre.008` : managers/apps/processus/IPC, norme des scenarios et orchestrateur futur.
|
||||
- première implémentation manager/service : mécanisme IPC et proxy distant Worker ;
|
||||
- futur : orchestrateur/application globale seulement lorsqu'un besoin opérationnel concret le justifie.
|
||||
|
||||
Reference in New Issue
Block a user