After Framework

Costruisci prodotti su un framework operativo condiviso.

Costruisci una volta. Distribuisci in ogni dominio.

After Framework offre ai prodotti una base condivisa: architettura, identità, IA, design system, strumenti e moduli di dominio riutilizzabili.

supercore/packages7 pacchetti · 2 linee di prodotto · 1 contratto di composizione
SuperGarageAfterHubSuperHospitalafter_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system
Legenda:dipendenza pubspecstack di riferimento documentato

01 · Architettura del framework

Un kernel. Due linee di prodotto. Prodotti snelli in cima.

Ogni prodotto condivide gli stessi livelli. Aggiungere un Life Domain o un Industry Domain significa aggiungere un modulo in cima: i livelli sottostanti non cambiano.

Specifico del prodotto

Piattaforma condivisa

Adapter della composition root

Seleziona un livello per vedere di cosa è responsabile e da cosa dipende.

after_core

Kernel condiviso

Autenticazione, networking protetto, storage, DI con Riverpod, flag, remote config, SDK di IA BYOK, diritti premium, notifiche, deep link e i motori di dashboard, plugin, ricerca e impostazioni.

Dipende da
Nessuna: livello di base
Usato da
Livello di dominio del prodotto · Livello di ecosistema · Capacità di IA · Moduli consumer · Moduli enterprise · Sistema di design · Adapter Firebase

Riuso condiviso, esperienza specifica del prodotto

La dottrina della piattaforma punta a far ereditare a ogni prodotto almeno il novanta per cento delle capacità di runtime. Un prodotto possiede il suo dominio, le funzionalità verticali, il profilo di IA, i cataloghi e il branding, nient’altro.

Le regole che tengono in piedi il sistema

  1. 01Port anziché SDK: il codice verticale dipende dalle interfacce After, mai dagli SDK dei fornitori.
  2. 02I moduli verticali vivono solo nei repository dei prodotti, in lib/features/.
  3. 03Ogni port include un mock, così gli scaffold girano senza backend.
  4. 04Generare, non ripartire da zero: i nuovi prodotti nascono da una spec, non da una nuova architettura.

02 · Fabbrica di prodotti

Dall’idea al prodotto funzionante su una base riutilizzabile.

La fabbrica di prodotti trasforma un piccolo product.spec.yaml in un’app Flutter affiancata che dipende dai pacchetti condivisi. La spec contiene solo ciò che è unico del prodotto.

  1. 01

    Idea

    Dai un nome al prodotto e scegli una linea: consumer o enterprise, con SuperGarage o SuperHospital come riferimento.

  2. 02

    Dominio

    Scrivi product.spec.yaml: dominio, funzionalità verticali, tab, permessi, widget della dashboard, skill di IA, branding, lingue.

  3. 03

    Moduli

    Tutto ciò che non è nella spec (autenticazione, membership o organizzazione, RBAC, calendario, attività, notifiche, ricerca) viene ereditato.

  4. 04

    Shell del prodotto

    generate_product.ps1 genera il manifest, la composition root, il catalogo funzionalità, la shell, i file l10n e un workflow di CI.

  5. 05

    Distribuzione

    Il workflow di CI generato esegue formattazione, analisi e test con copertura a ogni push e pull request verso main.

Il prodotto possiede

  • Nome, pacchetto, bundle, linea di prodotto
  • Funzionalità verticali e chiavi i18n
  • Tab di navigazione
  • Stringhe dei permessi RBAC
  • Widget della dashboard
  • Skill di IA e binding degli strumenti
  • Colore d’accento e monogramma

La piattaforma fornisce

  • Autenticazione e superadmin
  • Membership o organizzazione
  • Motore RBAC e log di audit
  • Calendario, attività, documenti
  • Notifiche e analytics
  • Motori di workflow, dashboard e ricerca
  • Sistema di design, splash, CI

Rieseguire il generatore con una spec aggiornata rinnova i file scheletro senza distruggere il codice delle funzionalità scritto a mano.

03 · Pacchetti e capacità

Sette pacchetti. Dipendenze esplicite.

Tutti i pacchetti sono alla versione 1.0.0 nel repository supercore e vengono usati tramite dipendenze di percorso. Seleziona un pacchetto per vedere da cosa dipende e cosa dipende da esso.

Kernel condiviso

after_core

Port e implementazioni predefinite per autenticazione, networking, storage, DI, analytics, feature flag, remote config, IA, notifiche, deep link e diritti premium. I prodotti sovrascrivono i provider Riverpod con i propri adapter.

Dipende da
Nessuna: livello di base
Usato da

API principali

  • AppPlatformManifest
  • PlatformConfig
  • AfterStandardOverrides
  • AfterBootstrapMode
  • AfterAuthRepository
  • AfterApiClient
  • AfterHttpClientFactory
  • AfterFeatureFlags
  • AfterRemoteConfig
  • AfterAiCredentialVault

Dipendenze di terze parti rilevanti

flutter_riverpod · dio · flutter_secure_storage · shared_preferences · google_sign_in · app_links · flutter_local_notifications

after_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system

Esempio

dart
import 'package:after_core/after_core.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:shared_preferences/shared_preferences.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  final prefs = await SharedPreferences.getInstance();

  runApp(
    ProviderScope(
      overrides: [
        afterSharedPreferencesProvider.overrideWithValue(prefs),
        afterAuthRepositoryProvider.overrideWithValue(MyFirebaseAuthRepository()),
        afterAnalyticsProvider.overrideWithValue(MyFirebaseAnalytics()),
        // ... store-specific adapters
      ],
      child: const MySuperApp(),
    ),
  );
}

Sorgente supercore/packages/after_core/README.md (si apre in una nuova scheda)

04 · CLI e flusso di lavoro

Script e comandi Flutter, nessuna magia.

Gli strumenti si trovano in supercore/scripts come script PowerShell, accanto alla toolchain Flutter standard. Non esiste un binario CLI distribuito a parte.

Inizializza

Valida una spec senza Flutter, poi genera l’app affiancata e avviala.

validate_product_spec.ps1
powershell -File scripts\validate_product_spec.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

Sorgente supercore/factory/README.md (si apre in una nuova scheda)

generate_product.ps1
# From a spec
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

# From a name only (quick starter)
powershell -File scripts\generate_product.ps1 -Name SuperAirport -Reference SuperHospital

# Preview without writing files
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml -DryRun

Sorgente supercore/factory/README.md (si apre in una nuova scheda)

flutter
cd ..\superairport
flutter create .
flutter pub get
flutter analyze
flutter test

05 · Dal framework ai prodotti reali

Le capacità condivise diventano esperienze specifiche del prodotto.

SuperGarage è il riferimento consumer già pubblicato. Ogni schermata qui sotto è un vero screenshot dello store; la sovrapposizione mostra quali parti arrivano dalla piattaforma e quali appartengono al prodotto.

Screenshot di SuperGarage: Punteggio di salute del veicolo e promemoria nella dashboard del garage.

Mappa delle capacità di SuperGarage

Identificatori importati da supergarage/lib, raggruppati per pacchetto di appartenenza.

after_core

  • AfterUserPlan
  • AfterAiCredentialVault
  • AfterLocalNotifications

after_consumer

  • FamilyShellHeader
  • AfterRegionalLocation

after_firebase

  • AfterFirebaseBootstrap

Funzionalità del prodotto

  • features/vehicle
  • features/maintenance
  • features/obd
  • features/expenses
  • features/fleet
  • features/trips
  • features/assistant
  • features/community

Famiglia di prodotti

Stato come registrato in supercore/catalog/products.yaml. Solo SuperGarage risulta pubblicato.

  • Icona di SuperGarage

    SuperGarage

    Consumer · Riferimento

    Mobilità: veicoli, manutenzione, assicurazione, carburante, OBD, flotta

    after_core · after_design_system · after_firebase · after_consumer

  • Icona di AfterHub

    AfterHub

    Consumer · Shell OS

    Shell OS consumer: identità, dashboard, IA, calendario, ricerca, After+

    Scaffold

    after_ai · after_consumer · after_core · after_firebase · after_design_system · after_ecosystem

  • Icona di SuperHospital

    SuperHospital

    Enterprise · Riferimento

    Operazioni ospedaliere: riferimento enterprise

    Scaffold
  • Icona di SuperHealth

    SuperHealth

    Consumer

    Salute personale: farmaci, cartelle, sonno, alimentazione

  • Icona di SuperFinance

    SuperFinance

    Consumer

    Finanza personale: abbonamenti, budget, investimenti

    Scaffold
  • Icona di SuperHome

    SuperHome

    Consumer

    Casa e famiglia: manutenzione, utenze, garanzie

    Scaffold
  • Icona di SuperTravel

    SuperTravel

    Consumer

    Viaggi: itinerari, voli, hotel, programmi

    Scaffold
  • Icona di SuperPet

    SuperPet

    Consumer

    Animali: cure veterinarie, cibo, cartelle sanitarie

    Scaffold
  • Icona di SuperNews

    SuperNews

    Consumer

    Notizie personalizzate dall’IA con riassunti

  • Icona di SuperSports

    SuperSports

    Consumer

    Sport e prestazioni: fitness, risultati, calendari

  • Icona di SuperAirport

    SuperAirport

    Enterprise

    Operazioni aeroportuali: voli, gate, piste

    Scaffold
  • Icona di SuperMaritime

    SuperMaritime

    Enterprise

    Operazioni portuali e navali

    Scaffold
  • Icona di SuperFactory

    SuperFactory

    Enterprise

    MES e manutenzione per il reparto produttivo

    Scaffold
  • Icona di SuperFarm

    SuperFarm

    Enterprise

    Operazioni agricole: colture, bestiame, attrezzature

    Scaffold

06 · Sistema di design

Coerenza senza uniformità.

after_design_system dà a ogni prodotto la stessa cornice, densità e animazione. I prodotti cambiano accento, monogramma, funzionalità e testi, non il sistema.

Token

Colore, spaziatura, raggio e animazione sono costanti Dart, condivise da consumer ed enterprise.

Colore

  • accent#38BDF8
  • accentDeep#0284C7
  • graphite950#0B0C0F
  • graphite800#222831
  • steel#8A919D
  • lightBackground#FAFBFC
  • success#22C55E
  • warning#F59E0B
  • danger#EF4444

Spaziatura · scala a 4pt

  • xs4
  • sm8
  • md12
  • lg16
  • xxl24
  • xxxl32
  • massive48
  • hero64

Raggio

  • 6
  • 8
  • 12
  • 16
  • 20

Animazione

  • instant100ms
  • fast · micro180ms
  • normal · page280ms
  • slow · modal420ms
  • emphasis560ms

Componenti

Pulsanti, schede, campi di input, navigazione, finestre di dialogo, grafici, dashboard, stati vuoti e di caricamento, sezioni delle impostazioni e barra superiore della shell.

  • buttons.dart
  • cards.dart
  • inputs.dart
  • navigation_bar.dart
  • dialogs.dart
  • charts.dart
  • dashboard.dart
  • empty_states.dart
  • loading.dart
  • settings_section.dart
  • shell_top_bar.dart

Accessibilità

Gli schemi di colore chiaro e scuro vengono forniti insieme. Le serie dei grafici sono ordinate per restare distinguibili e i token di animazione mantengono le transizioni brevi e mirate.

Comportamento responsive

Il padding della pagina e la larghezza del contenuto si adattano alla larghezza del viewport tramite AfterSpacing.

Larghezza viewportContenuto maxPadding pagina
< 360width14 / 10 / 14 / 28
360 – 41952016 / 12 / 16 / 28
420 – 71964020 / 12 / 20 / 28
≥ 72076020 / 12 / 20 / 28

Estensione del brand

Ogni spec di prodotto dichiara un accento e un monogramma. Il tema riceve l’accento tramite accentOverride; tutto il resto resta nella famiglia.

  • SuperGarage#22D3EE
  • SuperKids#F472B6
  • SuperHospital#F43F5E
  • SuperFactory#F59E0B

07 · Documentazione

Documentazione pensata per la consultazione rapida.

Ogni pagina è ricavata dal repository supercore e rimanda al proprio file sorgente.

  • Ricerca istantanea con scorciatoia da tastiera
  • Indice fisso con link diretti
  • Pulsanti di copia ed evidenziazione della sintassi in entrambi i temi
  • Pagine dei pacchetti con grafi delle dipendenze
  • Diagrammi di architettura con alternative statiche
  • Disponibile in dieci lingue, con supporto da destra a sinistra
Apri la documentazione

08 · Confini enterprise

Confini che falliscono in modo sicuro.

L’isolamento enterprise è imposto nel codice e registrato negli architecture decision record.

  • Tenancy fail-closed

    I port enterprise con ambito organizzazione richiedono un EnterpriseScope. Se manca organizationId viene generata un’eccezione: non restituiscono mai tutti i tenant.

  • Permessi prima della persistenza

    Le funzionalità verticali verificano PermissionSet.allows(...) prima di ogni chiamata che modifica dati. I prodotti dichiarano le proprie stringhe di permesso.

  • Audit append-only

    Ogni azione enterprise che modifica dati deve aggiungere un AuditLogEntry all’AuditLogRepository append-only.

  • Solo interoperabilità sicura

    Le chiamate tra prodotti passano da AfterSecureInteropBridge: audience After ID, scope, RBAC e appartenenza all’organizzazione, poi una voce di audit obbligatoria.

  • Avvio fail-fast

    In modalità produzione un adapter mancante genera un’eccezione all’avvio, così i provider mock non possono arrivare in produzione inosservati.

  • Modulare per costruzione

    I backend reali sostituiscono MockEnterpriseRepository nella composition root. Il livello OS non conosce mai il nome del fornitore.

enterprise_scope.dart
/// Fail-closed tenant + actor context for enterprise ports (ADR-002).
class EnterpriseScope {
  final String organizationId;
  final String actorId;
  final PermissionSet permissions;

  /// Throws if [organizationId] is missing/blank — never allow all-tenant lists.
  static String requireOrganizationId(String? organizationId) {
    final id = organizationId?.trim() ?? '';
    if (id.isEmpty) {
      throw StateError(
        'EnterpriseScope: organizationId is required (fail-closed tenancy).',
      );
    }
    return id;
  }
}

Sorgente supercore/packages/after_enterprise/lib/src/scope/enterprise_scope.dart (si apre in una nuova scheda)

Si tratta di controlli architetturali documentati nel repository supercore. After Framework non dichiara alcuna certificazione né conformità normativa.

Confini enterprise

Rendi il prodotto più piccolo. Rendi le fondamenta più solide.

Parti dall’architettura, leggi la documentazione dei pacchetti o esplora il sorgente.