Task #51
Updated by Daniele Cruciani 3 months ago
## Via Whatsapp, Lunedì mattino Whatsapp 9:21, io: > Le convenzioni e le modalità con le quali due persone sono felici assieme non hanno bisogno dell’approvazione sociale. Non è la mia vita privata o la supposta qualità di vita privata che devi giudicare, ma solo gli aspetti professionali. Forse hai l’impressione che io abbia problemi comunicativi per una insoddisfazione a livello relazionale, ma ci sono aspetti tecnici comunicativi a cui dai poco peso ed importanza, e questi generano conflitti continui. > In qualche maniera ti rifiuti di riconoscerli, e lo hai sempre fatto, quando consiglio un libro come Domain Driven Design, che è piuttosto palloso e difficile da leggere, è perché evidenza quanto sia palloso e difficile interagire tra chi approccia la soluzione dal punto di vista della logica di business, e chi approccia la soluzione dal punto di vista implementativo. > Pensare che logica di business e architettura del sistema siano perfettamente sovrapponibili è la cosa più semplice da farsi, la cosa che sembra più semplice da mantenere, la cosa che sembra più semplice ed efficace da implementare. > > Eric Evans ha scritto circa 500 pagine di testo per spiegare un caso studio per una applicazione bancaria, ambito nel quale gli errori nel software non sono ammessi, e la consistenza dei dati è critica. > > Ha scritto 500 pagine, ma nonostante tutto non si capisce esattamente di cosa parla. Fino a che non ci si scontra con un problema simile. In realtà, con molti problemi simili. > > Ogni volta che hai una necessità, una funzionalità, un’idea, quell’idea è ragionata secondo le logiche di business, e non secondo le logiche implementative, che emergono solo durante l’implementazione della soluzione. > > Inoltre c’è una necessità contingente, che è quella di poter andare a modificare alcune parti del sistema, in isolamento. Questo concetto sembra che sfugga completamente a tutti in azienda. Scrivere microservizi, scrivere classi separate con responsabilità definite, e tutta questa roba, serve a poter garantire l’implementazione veloce di nuove funzionalità, per poter garantire l’analisi veloce dei problemi, per poter allungare la vita ad ogni singolo modulo (microservizio o classe). In sostanza serve per rispondere più prontamente al mercato, e mantenere al tempo stesso stabilità. > > Visto che la logica di business non coincide esattamente con l’architettura che la implementa, quando si riportano problemi, è sempre richiesto che si riportino gli eventi, e non la spiegazione. Questo per 2 ragioni: la spiegazione potrebbe non essere esatta, e si perde la sequenza degli eventi. C’è una terza ragione: la revisione e il refactoring dell’architettura. Sì, perché alcuni approcci sensati dal punto di vista della business logic, non lo sono implementativamente, e questo può emergere anche dagli eventi anomali. In sostanza l’evento anomalo (bug) evidenza delle carenze architetturali, ma solo se l’evento è descritto per quello che è, non per la spiegazione che gli si da. Altrimenti bisogna fare tutto un lavoro di indagine aggiuntiva. > > Quando mi siedo per programmare, spesso è dopo un duro allenamento, quindi l’ultima cosa che voglio è disturbare gli altri, voglio che questa attività sia rilassante come la percepisco io: mi siedo, progetto, e scrivo codice. Evito e automatizzo tutto ciò che è ripetitivo, tolgo la parte noiosa, e mi concentro sulla soluzione. > > Solo che, come ho cercato di spiegare, logica di business e soluzione architetturale non sempre coincidono. E questo è un *valore* per la capacità del sistema di rispondere alle richieste di mercato, ma è una cosa grossolanamente ignorata e svalutata. > > Anche il vocabolario della logica di business ed il vocabolario della logica architetturale, non sempre coincidono. > > Persino l’organizzazione del database, non è necessariamente coincidente con la logica di business. > > Non scambiamo valori per disvalori semplicemente perché non sono facilmente apprezzati senza un’adeguata analisi e confronto con altre realtà. Considera che è la stessa cosa in ambito bancario, quindi non è che vado altrove e trovo meglio, probabilmente vado altrove e trovo colleghi che già vivono questo conflitto, oppure una cultura aziendale condivisa che riconosce questa discrepanza di vocabolari e la percepisce come valore. > > Ogni valore ha un costo, ovviamente, ma cancellare un vocabolario, come suggerisci tu, Chris, e anche un po’ Gunter, senza neanche averlo aperto, mi sembra una idea piuttosto approssimativa ed affrettata. E il vocabolario non è docker help, il vocabolario sono le varie architetture, i moduli, le classi definite, i pattern utilizzati nei singoli micro servizi, l’uso che viene fatto del message broker, e via dicendo. 9:29, io: > *quick&dirty* non è solo sporco e veloce, ma rompe e annulla questo valore, le modifiche fatto per soddisfare velocemente qualcuno, non tengono conto di altre logiche adottate, e di conseguenza l’obiettivo di avere un sistema facilmente modificabile, controllabile, consistente, e che risponda velocemente alle richieste di cambiamento è sabotato. > Quick&dirty è solamente dirty&destructive. > Per di più, non è affatto detto che rispondere velocemente alla richiesta del cliente sia un valore: se mostri che quello che chiede può essere soddisfatto immediatamente, il valore che percepisce il cliente è che quella cosa è semplice e di poco valore, ci vuole poco sforzo, vale poco. 10:21, io: > *500 euro*, ma in realtà sono molte di più quelle che butteresti