124. Multiple models
Web Application Context
Banking Context
Account
Account
La consapevolezza della presenza di più
modelli, può aiutarci ad avere una visione
d’insieme più nitida
Copyright Alberto Brandolini
126. Team A Team B
Organization Level
e
r on t
One h e e re n
p r i m te am e ot ff
a r i l wo r e t h a di
y k
c l a s o n s om s hi l s o n rt io n
se s e . . .w o r k p o
w
A'
Context Level
A
...c
be onc
c om e p
slo e s e t ua l
wl xp int
y s en eg
li p si v r i t
sa ea y
wa n d
y
Copyright Alberto Brandolini
132. Tactical DDD Strategic DDD
Patterns da applicare al
Pattern da riconoscere
design della nostra
nello scenario di progetto
applicazione
applicabili in un
riconoscibili in ogni
ecosistema ben
ecosistema
definito
Design duttile ...Context Map?
Copyright Alberto Brandolini
133. Our context map
Big Ba l l
of Mu d
Context Context F
C !
u Context A
AC
d pe n
L
d O
Hos t
Context u
B Context Context
E
D
138. “Le battaglie sono
vinte prima di essere
combattute”
Sun Tzu
“La tattica senza
strategia è solo
rumore prima della
sconfitta”
Sun Tzu
139. Modello a risorse finite
Progetti complessi
richiedono una corretta
valutazione dello
scenario in cui
operiamo.
Le risorse disponibili
per un progetto non
sono infinite
La definizione originale è in qualche modo sfuggente: non si tratta di una metodologia con regole precise. Si tratta di qualcosa di meno strutturato: un approccio o un atteggiamento nei confronti dello sviluppo software.
Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilità che permettono di migliorare notevolmente l’efficacia del nostro approccio alo sviluppo del software.
Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilità che permettono di migliorare notevolmente l’efficacia del nostro approccio alo sviluppo del software.
Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilità che permettono di migliorare notevolmente l’efficacia del nostro approccio alo sviluppo del software.
Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilità che permettono di migliorare notevolmente l’efficacia del nostro approccio alo sviluppo del software.
La gestione di contesti complessi è stata negli anni passati il cavallo di battaglia di OOP. Tutto l’impianto teorico di OOP nasceva per una corretta gestione della complessità. Tuttavia alcune delle buzzword - il mito del riuso per citarne uno - non hanno mantenuto le promesse iniziali. Soluzioni realmente riusabili sono apparse successivamente, in forma di patterns (GoF, GRASP, POSA, PEAA etc…). Il focus è stato principalmente sull’architettura: la neutralità rispetto al dominio garantiva infatti una maggiore riusabilità.
L’unica eccezione notevole degli ultimi anni a questo trend è stato il libro di Martin Fowler Analysis Patterns.
Questa ovviamente non è una premessa per qualsiasi progetto: è tuttavia lo scenario più adatto per applicare i principi di Domain Driven Design. O meglio quelli di “Tactical Domai Driven Design” (la differenza sarà più chiara in seguito).
C’è comunque una scelta strategica di fondo. Un dominio complesso non può essere catturato a costo zero, il lavoro di ricerca ha un costo che si ripaga fornendo un vantaggio competitivo. Inoltre si tratta di un asset che ha valore nel tempo e pertanto va mantenuto indipendente dalla tecnologia circostante che varia secondo ritmi e forze completamente differenti.
Domain driven design può avvenire in un contesto ben preciso, solo se determinate condizioni sono verificate. Questo ecosistema è relativamente fragile e presuppone un contesto fortemente collaborativo che favorisca la creatività.
Un contesto di sviluppo agile è necessario in particolare per una caratteristica che accomuna tutte le metodologie, ovvero l’esasperata ricerca del feedback, in ogni sua forma.
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Giuliano Moggi,
Giulio Andreotti,
Licio Gelli,
Giuseppe Cossiga,
Tommaso Buscetta,
Hannibal Lecter.
Cos’hanno in comune queste persone?
Si tratta di esperti di dominio (e che avevate pensato…).
Si tratta di persone che sanno un sacco di cose, cose che ci interessano ma che non è detto che siano così inclini a rivelare. Conoscono la loro materia ad un livello profondo e sono in grado di dirci i perchè. Il canale di comunicazione con l’esperto di dominio è forse il single point of failure più delicato di tutto l’impianto di DDD.
Siamo interessati ad una collaborazione creativa, difficile, ma preziosa ed incredibilmente potente.
Si tratta di esperti di dominio (e che avevate pensato…).
Si tratta di persone che sanno un sacco di cose, cose che ci interessano ma che non è detto che siano così inclini a rivelare. Conoscono la loro materia ad un livello profondo e sono in grado di dirci i perchè. Il canale di comunicazione con l’esperto di dominio è forse il single point of failure più delicato di tutto l’impianto di DDD.
Siamo interessati ad una collaborazione creativa, difficile, ma preziosa ed incredibilmente potente.
Il nostro lavoro è in larga parte un percorso di apprendimento. Siamo pagati per imparare i risvolti più nascosti del dominio.
Con ogni mezzo disponibile… (possiamo essere creativi anche nell’apprendimento)
L’apprendimento non è un processo lineare, passa attraverso errori e ravvedimenti. Non è detto che questo corrisponda ad un’accumulazione di story points iterazione dopo iterazione in un modo statisticamente prevedibile.
Breakthrough s refactoring sono gli strumenti che ci permettono di fare evolvere la nostra applicazione verso una conoscenza del dominio sempre più raffinata.
L’obiettivo è la realizzazione di un modello.
Cosa intendiamo esattamente?
La mappa della metropolitana di Londra. Utilissima per chi si muove nella grande metropoli.
La rappresentazione NON è fedele, il Tamigi sicuramente non è ad angoli retti, ma ciò non compromette l’utilità dello strumento.
Un’altra mappa di Londra, via google maps.
Il dominio mappato è lo stesso, con fedeltà maggiore. Il focus in questo caso è sulla rete stradale.
Un’ulteriore mappa sempre riferita allo stesso dominio. Il livello di dettaglio e la fedeltà è sicuramente maggiore. Ma l’utilità per un utente della metropolitana è decisamente inferiore.
Questa cosa del modello perfetto è stata per anni una perversione degli analisti OOP.
Il succo del ragionamento era (ci sono passato anche io…) “Se gestisco un numero sufficiente di casistiche allora il mio modello potrà essere riutilizzato anche in altri contesti”.
È l’uso a definire le caratteristiche e la conseguente utilità del modello. Il modello serve a qualcosa. Capire a cosa ci aiuta nella costruzione del modello più adatto.
Esiste una sola rappresentazione del modello che ci garantisce l’allineamento con il comportamento del sistema. Il codice. Tutto il resto serve ad uno scopo intermedio.
Una rappresentazione UML può tornare utile in determinati contesti, ma controproducente in altri. UML è uno strumento di comunicazione, e se finisce per introdurre una barriera che ostacola la comunicazione allora può darsi che non sia lo strumento adatto. In ogni caso il contenuto della comunicazione e l’efficienza del canale sono immensamente più importanti del linguaggio in cui il contenuto viene espresso.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
In alcuni casi, l’uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso è probabilmente il compromesso migliore.
Il design è un’attività che implica confronto. Se avviene in isolamento non è decisamente un buon segnale.
Il meccanismo di controllo - la prova del 9 - sul fatto che le cose stiano andando nel verso giusto è rappresentato dallo Ubiquitous Language. Non deve esistere alcun passaggio di traduzione. I concetti espressi a livello di conversazione con l’esperto di dominio devono avere una loro controparte a livello di codice. Ogni termine deve essere semanticamente definito con precisione.
L’ambiguità è il nostro peggior nemico.
Come costruire il modello in un generico linguaggio ad oggetti? Java, C# etc...
Un vero domain model è necessario. Si tratta di un paradigma architetturale noto da tempo ma che ha conosciuto alterne fortune. È interessante notare la caratterizzazione che ne da Fowler: è più difficile da ottenere, ma una volta che gli sviluppatori prendono dimestichezza, non tornano più indietro.
Si tratta in ogni caso di uno strumento raffinato che richiede una certa padronanza dei principi fondamentali di OOP.
Architetturalmente questo definisce un luogo ben preciso dove accadono le cose: il domain layer. Uno strato completamente indipendente dalla tecnologia dove concentrarsi unicamente sulla realizzazione di un modello utile ed efficace.
I principi di ragionamento di DDD non differiscono di molto da quelli classici della OOP: c’è la proposta di archetipi ripetibili ed un pragmatismo di fondo che mitiga alcuni estremismi.
Questa è senza dubbio la parte più famosa di DDD. Molti lettori non hanno superato la metà del libro. Si tratta di mattoncini utili per la costruzione di un modello di dominio equilibrato e coerente.
Notare la genericità dei termini, non ho detto database.
In ogni caso, il focus non è tanto la corrispondenza delle classi con un a tabella sul database (che potrebbe dare adito ad un anemic domain model), quanto il fatto che l’applicazione tiene traccia del ciclo di vita delle nostre entità. Per certi versi l’intera applicazione non è altro che una gestione delle transizioni di stato delle nostre entità.
I Value Objects sono componenti decisamente più semplici: la loro caratteristica più importante è l’immutabilità. Non evolvono e questo rappresenta una drastica semplificazione del software necessario a gestirli.
I services rappresentano azioni caratteristiche del dominio. Spesso sono punti di accesso a complessità che avviene in altre parti dell’applicazione. Imporre una gestione stateless semplifica grandemente la scalabilità.
Gli aggregati rappresentano un insieme di classi con un’unità logica complessiva. I confini dell’aggregato (non stiamo parlando di aggregazione UML) coincidono spesso con quelle della propagazione della cancellazione, con i confini transazionali, con un unità di trasporto significativa nel caso di applicazioni distribuite.
Anche in questo caso non stiamo parlando di un Pattern specifico. GoF sviscera il tema dei Factory giungendo in alcuni casi alla perversione. In DDD l’enfasi non è sulle meccaniche o sul come implementare un factory, quanto sul fatto che la creazione di un oggetto rappresenti una responsabilità che è logicamente svincolata dagli altri compiti della classe, quindi è bene che sia esternalizzata. Diversi supporti tecnologici possono aiutarci in misura diversa in questo campo (es. Dependency Injection).
Un repository è il punto di confine tra il nostro Domain Model ed il mondo della persistenza. Ci sono (almeno) due linguaggi che agiscono nello stesso punto (OO, SQL, ORM specific… ). Il Repository dovrebbe astrarre rispetto alla complessità e gestire le operazioni di persistenza ad un livello logico.
In alcuni casi il disaccoppiamento logico che viene ottenuto può non risultare un vantaggio determinante, ma l’introduzione di differenti strategie di persistenza alternative al RDBMS ha riaperto i giochi anche in questa porzione dell’applicazione.
Si tratta di un’aggiunta rispetto alla formulazione del libro. In alcuni casi, la complessità dell’aggregato da rendere necessario un ruolo di coordinamento dell’intera struttura, in una classe a parte.
Anche in questo caso si tratta di una new entry. Alcuni eventi caratteristici del sistema sono immutabili (come i VO) ma con un’identità molto chiara (come le entity). I Doain Event colmano questa lacuna.
Per arrivare alla costruzione del nostro design duttile, altri elementi entreranno in ballo. Influenzando largamente il nostro stile di scrittura trasformando il nostro codice in qualcosa di molto simile ad un DSL. In alcuni linguaggi questo sarà più facile che in altri, ma il succo è la possiblità di poter disporre di uno srumento duttile e potente tra le mani che accorci la distanza tra pensiero (del domain expert) ed azione (dell’applicazione)
L’effetto combinato dei vari pattern è decisamente interessante. Si tratta di una struttura emergente con caratteristiche ripetibili.
La caratteritica più interessante è che determinate complicazioni insite nel dominio semplicemente smettono di presentarsi. Il dominio risulta già “pettinato” prima di costruirci un’applicazione sopra. La struttura risultante è logicamente ordinata.
Sono famiglie, archetipi ripetibili. Non tutte le famiglie hanno tutti i nonni. non tutte le famiglie hanno 2 figli ma siamo in grado di riconoscere le famiglie e di comprendere la suddivisione dei ruoli al loro interno.
Si tratta di un meccanismo che permette di scalare il nostro domain model, mentre le formulazioni classiche finivano prima o poi per incartarsi. Con DDD riesco ad andare oltre… ma di quanto?
Per capire meglio cosa succede nel passaggio dalla teoria alla pratica dobbiamo cambiare approccio e prospettiva.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Gli strumenti appena visti ci permettono di gestire la complessità del dominio applicativo “senza incartarci”, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
Però il modello a cui facciamo riferimento è oltremodo semplificato. Un solo progetto, un solo team. La complessità dei progetti reali in realtà può essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilità delle nostre scelte.
L’altro elemento di semplificazione irreale è la presunzione di poter cominciare un progetto dal foglio bianco. Nel 2009 avremo sempre e comunque a che fare con applicazioni Legacy e con tutti i problemi che queste comportano.
I nostri sogni di conquista incontrano un primo ostacolo. Non possiamo estendere il nostro approccio indefinitamente.
Es: “Papi”… :-)
... and the Romans were amongst then
They were not originally meant to be part of the system
In questo esempio un team è cresciuto di dimensioni fino a dividersi in due. la comunicazione diventa meno efficace, ed in alcuni classi possono apparire classi simili che risolvono in maniera differente lo stesso problema.
Soprattutto nella terra di nessuno tra più contesti, quella dove è difficile individuare un responsabile.
Apparentemente un ovvietà: in realtà questa affermazione inizialmente era uno scherzo, ma studi scientifici più approfonditi hanno dimostrato che era assolutamente vera, e che il fattore determinante era la distanza fra i team nell’organigramma aziendale, più che la vicinanza fisica.
As ugly and dirty as it might look...
è comunque una mappa. Uno strumento per leggere il territorio, e piazzare le nostre truppe laddove possono essere più efficaci contro il nemico.
N.d.r. Questa è la mappa della battaglia di Austerlitz, dove Napoleone ha vinto … non si sa mai ...
E’ necessaria una visione diversa, che ci permetta di non farci trascinare in battaglie che non possono essere vinte, con il rischio di ritrovarci frustrati perché nonostante le migliori intenzioni non siamo riusciti a portare a casa i risultati sperati.
E’ necessaria una visione diversa, che ci permetta di non farci trascinare in battaglie che non possono essere vinte, con il rischio di ritrovarci frustrati perché nonostante le migliori intenzioni non siamo riusciti a portare a casa i risultati sperati.
La scienza opera delle semplificazioni per spiegare i fenomeni, ma nella pratica spesso si deve fare i conti con il fatto che la semplificazione sia … una semplificazione.
Per anni si è pensato al petrolio come ad una risorsa inesauribile, così come all’atmosfera. Ora facciamo i conti con un sistema geopolitico in cui consideriamo il petrolio come una fonte in potenziale esaurimento e dove i cambiamenti climatici ci costringono a ripensare molte delle nostre azioni, perché avevamo tralasciato di considerare le conseguenze...
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare.
Gli sviluppatori sono spesso considerati “carne da cannone”: il numero e la provenienza non è un problema.
la comunicazione, o meglio il tempo allocato per lo scambio di informazioni è forse la grandezza meno considerata in sede di large scale project management. Ma la quantità di informazioni che può essere scambiata in una grande organizzazione è una grandezza finita.
Nonostante le aziende continuino a trattarci come parte di una “intelligenza collettiva” non c’è alcuna speranza che le informazioni circolino solo perchè sono state messe sul Wiki, o che tutti gli sviluppatori siano continuamente aggiornati via RSS Feed su tutto ciò che avviene nel progetto.
In realtà nei progetti di grandi dimensioni è facile la situazione opposta: la quantità di informazioni da sapere prima di poter scrivere una sola riga di codice è (teoricamente) talmente elevata che, specialmente in caso di turnover, la maggior parte di queste viene bellamente ignorata.
Nell’immagine un soldato giapponese catturato dagli americani al termine della seconda guerra mondiale. Molti militari di stanza nel pacifico continuarono a combattere a lungo senza essere informati della fine delle ostilità.
Mettersi d’accordo è una delle forme di comunicazioni più sofisticate che esistano tra esseri umani: implica
comprensione del problema da ambo le parti
individuazione di possibili soluzioni
raggiungimento di un compromesso soddisfacente
...non avviene per caso o per fortuna.
La gestione a turnover selvaggio, di “risorse intercambiabili” complica ulteriormente il problema. È molto semplicemente un incentivo all’ignoranza.
Le persone non sono tutte uguali, per le capacità, per il rendimento, la competenza etc etc etc. trattarle come intercambiabili significa avere il minimo rendimento da ciascuna di esse.
In definitiva, fare la cosa giusta è realmente la cosa più difficile.
Cosa rende speciale la nostra azienda (o l’azienda nostra cliente)?
Come possiamo massimizzare il valore prodotto?
Come possiamo definire il successo della nostra applicazione?
non è morto nessuno?
nessuno ci ha denunciato?
abbiamo consegnato qualcosa?
abbiamo consegnato in tempo?
gli utenti hanno usato l’applicazione?
gli utenti hanno apprezzato l’applicazione?
l’applicazione ha aumentato i profitti del nostro cliente?
le persone sono più felici perché esiste la nostra applicazione?
Lavorare pensando solo alla riduzione dei costi porterà a tagliare la qualità o a fare applicazioni “come quell’altra”. Vogliamo applicazioni che apportino dei benefici.
DDD richiede risorse “speciali” e quindi non può essere applicato a tappeto. Dobbiamo capire dove questo possa apportare dei benefici.
È estremamente raro che la tecnologia in se per se possa rappresentare un vantaggio competitivo. Ancora più raro che questo sia durevole.
Noi abbiamo già una mappa, e la conoscenza del terreno è fondamentale per prendere le decisioni corrette.
È puro realismo. Un’applicazione uniformemente ben progettata non esiste. E’ importante che sia ben progettata dove serve, ed abbastanza ben progettata nelle altre parti.
Cos’è importante e cosa no non dipende da noi, ma dipende dallo scenario business.
Solo interagendo con l’area business possiamo pensare di fare la cosa giusta, al momento giusto.