La strategia dietro al codice.

Un approccio consolidato alla progettazione del software.

La fondazione di strumenti che durano nel tempo
Domain-Driven Design

Il codice parla la tua lingua.

Oggi, la parte difficile di scrivere software non è la tecnologia: è la capacità di allinearlo al business in maniera verticale. Per questo modelliamo prima il dominio: processi, regole e concetti, in modo comprensibile per chi lavora.

01

Un linguaggio condiviso

Una definizione per ogni concetto: la stessa in riunione, nei requisiti e nel codice. Nessun malinteso fra chi conosce il mestiere e chi scrive il software.

02

Contesti delimitati

Reparti aziendali differenti usano le stesse parole con significati diversi. Invece di forzare un modello unico, disegniamo confini espliciti e definiamo come i contesti comunicano tra loro.

03

Aggregati e invarianti

I modelli impongono regole inviolabili in punti ben definiti. Le entità di business non vengono messe in produzione con uno stato non valido perché è il modello a impedirlo, da ovunque arrivi la richiesta.

04

Dominio isolato dalla tecnologia

Le regole di business non dipendono da database, framework o fornitori: quelli rimangono al di fuori e sono intercambiabili.

Un esempio:Collaudonel codice: Inspection
  1. Riunione

    «Nel caso in cui non dovesse passare il collaudo, la commessa non parte.»

  2. Requisito

    Una commessa deve avere traccia di un collaudo superato, altrimenti non deve essere spedita.

  3. Codice
    class JobOrder {
      ship() {
        if (!this.inspection.passed) {
          throw new InspectionNotPassed()
        }
      }
    }
  4. Tabella
    inspections
      job_order_id · passed · performed_at
Affrontiamo le problematiche

Imprevisti? Succede.

I progetti software spesso incontrano ostacoli simili: la differenza la fa chi li ha già superati più volte.

1.Un piano ben definito

Prima di sviluppare mappiamo processi, vincoli e obiettivi. L'analisi non è un allegato al preventivo: è la prima cosa che consegniamo, ed è già un risultato che resta tuo.

2.Requisiti scritti per essere verificati

Trasformiamo le idee in specifiche concrete: ogni funzionalità ha un perché e un criterio di accettazione. Così "finito" significa la stessa cosa, per te e per noi.

3.Costruiamo per il cambiamento

Usiamo cicli brevi e architetture modulari. Quando le priorità cambiano, il progetto si riorganizza senza ripartire da zero: il cambio di rotta è previsto, l'impatto è minimo.

Sviluppo con intelligenza artificiale

AI? Sì, ma....

Usiamo agenti sintetici per scrivere software più in fretta: il loro comportamento è però basato su una serie di convenzioni ben definite che abbiamo evoluto nel tempo, e che continuiamo a migliorare.