Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.0.3-pre.010

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 13:05:50 +02:00
parent 2dada316c1
commit 5e169af906
16 changed files with 283 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-LAYERS_AND_DEPENDENCIES.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Couches et dépendances KSP
@@ -32,7 +32,7 @@ Une bibliothèque N1 ne doit pas dépendre d'une fonctionnalité métier située
N2 regroupe les capacités réutilisables opérant sur Solana au-dessus des fondations.
Le nom `ksp-program-lib` est retenu pour la future bibliothèque propriétaire du traitement des programmes : décodage et opérations techniquement constructibles/exécutables. Elle doit s'appuyer sur `ksp-interface-lib` plutôt que faire porter les contrats wire aux applications.
Le nom `ksp-program-lib` est retenu pour la bibliothèque propriétaire du traitement des programmes : décodage et préparation technique d'opérations via `ProgramExecutionPreparer`. Elle doit s'appuyer sur `ksp-interface-lib` plutôt que faire porter les contrats wire aux applications.
Les autres responsabilités N2 candidates comprennent notamment :
@@ -72,11 +72,11 @@ W1 :
- ne décide pas de l'utilisation métier des données collectées ;
- doit pouvoir faire évoluer à chaud ce qu'il écoute, rapatrie ou stocke selon les mécanismes de configuration/commande qui seront définis.
Les consommateurs des notifications W1 décident eux-mêmes s'ils doivent décoder, matérialiser ou effectuer un autre traitement.
Les notifications W1 servent de wake-up. Les workers/jobs downstream reconstruisent leur backlog depuis le Store et appliquent les pipelines spécialisés correspondant aux frontières D1 -> D2 -> D3 -> D4.
### Workers de processing futurs
Le processing continu n'est plus modélisé comme un unique W2. La direction actuelle sépare `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` afin de respecter les frontières durables D1 Raw -> D2 Core -> D3 journal de matérialisation générique -> D4 projections de domaine. Leur détail sera repris dans la tranche consacrée aux workers/data.
Le processing continu n'est plus modélisé comme un unique W2. Il sépare `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` afin de respecter les frontières durables D1 Raw -> D2 Core -> D3 journal de matérialisation générique -> D4 projections de domaine. Le lifecycle, backlog, claim/lease et replay sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
## N4 — Exécutables
@@ -141,7 +141,7 @@ Les workers sont différents des interfaces utilisateur. Ils peuvent contenir l'
Un worker doit néanmoins consommer les bibliothèques KSP propriétaires des contrats Solana et ne doit pas dépendre directement de crates Solana/protocoles externes.
Les premiers managers de workers peuvent être spécialisés et séparés. Un orchestrateur global sera introduit ultérieurement lorsque plusieurs workers/managers justifieront réellement cette abstraction.
Les premiers managers de workers sont spécialisés et séparés. Une application globale est un produit futur, tandis qu'un orchestrateur commun reste une abstraction à réévaluer seulement lorsqu'un besoin opérationnel concret le justifie.
## Firewall des dépendances externes
@@ -182,7 +182,7 @@ Les contrats minimaux entre couches doivent être définis suffisamment tôt pou
Ce principe s'applique notamment aux futurs :
- decoders ;
- executors/constructeurs d'opérations ;
- `ProgramExecutionPreparer` / constructeurs d'opérations ;
- materializers ;
- store/repositories ;
- transports ;
@@ -194,9 +194,9 @@ Il ne signifie pas qu'il faut implémenter prématurément toutes les fonctionna
## Questions encore ouvertes
- représentation interne exacte du type d'erreur commun KSP ;
- découpage interne précis de `ksp-program-lib` ;
- politique de sécurité/exécution située au-dessus de `ksp-program-lib` ;
- position précise du pipeline et du futur orchestrateur ;
- représentation interne exacte du type d'erreur commun KSP, à traiter dès `0.1.1-pre.001` ;
- types publics précis de `ksp-program-api` et format ouvert/persistable des résultats décodés ;
- méthode de conformité wire contre les projets externes ;
- graphe de dépendances précis crate par crate.
- mécanisme IPC du premier manager de worker autonome ;
- besoins de contexte des futurs `DomainProjector` stateful ;
- nécessité réelle d'un orchestrateur commun lorsque plusieurs services/managers existeront.