Puoi trattare la "documentazione del linguaggio ubiquitario" come un progetto di personalizzazione del software: devi prendere un po 'di software per la gestione della documentazione e adattarlo alle tue esigenze specifiche. Nei progetti software normalmente si inizia con la raccolta delle esigenze degli utenti, quindi si costruisce l'architettura delle informazioni e la soluzione di progettazione e quindi si procede all'implementazione. Di seguito è riportato l'esempio di questo processo.
Quali sono le esigenze dell'utente per questo? In alcune organizzazioni le persone con funzioni diverse provenienti da domini diversi vogliono usare il linguaggio comune per descrivere i loro problemi e soluzioni. Questo dialetto sarà definito unicamente dal suo vocabolario (parole e figure retoriche), poiché la pronuncia probabilmente non è importante qui e la grammatica si baserà sulla forma letteraria della lingua. Per documentare il dialetto, è necessario progettare una struttura di documentazione che sia la più adatta alla gestione di un vocabolario (glossario dei termini).
Le persone potrebbero voler utilizzare questa documentazione per apprendere il significato della parola o dell'acronimo, per trovare la parola corretta con il suo sinonimo o definizione o per apprendere tutte le parole che compongono il dominio.
Per queste esigenze dell'utente, wiki è davvero una buona scelta. Come si adatta?
In un buon sistema wiki come Confluence o MediaWiki è possibile:
- Crea un articolo per ciascun termine.
- Definisci la struttura comune degli articoli in alcuni modelli, in modo che contengano alcune sezioni comuni, che possono essere utilizzate per l'aggregazione.
- Aggiungi facilmente collegamenti alle definizioni dei termini in altri articoli wiki.
- Crea tabelle aggregate con definizioni di termini e incorporale in altra documentazione.
Attualmente sto usando Confluence per documentare l'architettura delle informazioni e le definizioni del linguaggio ubiquo fanno parte di esso. Il livello più alto di questa documentazione sono articoli di dominio. In ogni applicazione ci sono più domini, ad es. sicurezza, pagamenti ecc. Questi domini sono definiti da un numero di interazioni dell'utente con il sistema, che può essere descritto tramite un linguaggio ubiquo, quindi inserisco le definizioni di queste interazioni in sottopagine separate e le definizioni di termini introdotte da queste interazioni nelle sottopagine delle pagine di interazione. Inserisco tabelle aggregate sulle pagine padre in modo che sia possibile vedere, ad esempio, quali scenari costituiscono il dominio e quali termini sono definiti in esso.
Quando questa struttura della documentazione è completa e passo a specifiche di sistema più dettagliate, posso semplicemente fare riferimento alle definizioni IA e UL degli scenari, ad es. "Il componente A implementa l'integrazione con il sistema B per supportare l'interazione C (link dello scenario IA) passando informazioni su Z (UL link)".