Architettura core first
PayCal Core contiene la logica canonica di dominio e controller: calcoli, validazione, permessi, policy del ciclo di vita e contratti API condivisi.
Il core resta intenzionalmente agnostico rispetto alle estensioni. I punti di integrazione sono isolati tramite contratti bridge così che i servizi core possano essere testati indipendentemente dai pacchetti specifici del runtime.
Estensioni base incluse in questo repository
Questo repository include implementazioni base di estensioni che forniscono comportamento predefinito per i punti di estensione. Fungono da pacchetti di riferimento pubblici e da valori sicuri per i deployment self-hosted.
- billing-provider: hook base per fatturazione e selezione modalità
- earnings-ytd: rendering YTD base e punti di aggancio per gli earnings
- organization-signals: hook base per i segnali dell’organizzazione
Modello di estensioni di terze parti
Le terze parti che usano questo repository possono creare e mantenere i propri pacchetti di estensione. Il modello atteso è:
- Mantenere il più possibile invariata la logica core
- Implementare il comportamento personalizzato nei pacchetti di estensione
- Collegare i pacchetti personalizzati tramite bootstrap e hook seam documentati
- Preservare i contratti core per rendere gestibili gli aggiornamenti upstream
Questo consente deployment competitivi e specifici per settore senza forzare fork a lungo termine del codice core.
Differenziazione canonica di paycal.app
La piattaforma canonica https://paycal.app esegue varianti private di estensione sopra lo stesso paradigma core e di estensioni base.
Queste varianti private sono un livello deliberato di differenziazione del prodotto per gli ambienti gestiti da PayCal. Possono adattare workflow, comportamento delle capability e integrazioni specifiche dell’interfaccia mantenendo la compatibilità con la stessa architettura core.
- La logica core resta condivisa e verificabile
- Le estensioni pubbliche/base restano disponibili nel repository
- Le estensioni private forniscono la differenziazione canonica della piattaforma
Impegni di trasparenza
- I contratti core sono documentati e testati ai punti di estensione
- I confini del bridge sono espliciti per rendere visibile il coupling
- Il comportamento delle estensioni può evolvere senza destabilizzare i servizi core
- Gli utenti self-hosted possono costruire strategie di estensione alternative