Domain Driven Design
Alessandro Melchiori da qualche settimana millanta che avrebbe scritto dei post inerenti all’argomento Services UI Composition, ecco millanta :-D Forza Ale pubblica qualcosa! Per cercare di smuovere ancora un po’ le acque sto preparando una nuova sessione che al momento è così definita: Tutti i nostri aggregati sono sbagliati Inizia sempre tutto bene, il requisito è semplice e l'implementazione procede senza intoppi. Poi i requisiti aumentano e ci ritroviamo con una strana sensazione allo stomaco e con la necessità di introdurre alchimie tecnologiche che non ci piacciono, ma non sappiamo...
Volete capire come progettare e gestire i cosiddetti “long running busness process” in un mondo basato su Microservices in maniera affidabile ed efficace? Workshop: Microservices development deep dive. Il programma, parte 3: Saga Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La terza parte evolve dalla sessione precedente introducendo il concetto di “long running business process” o se vogliamo, in maniera più volgare, workflow; affronteremo quindi, dal punto di vista architetturale prima e tecnologico poi, concetti come Saga, Orchestrator e Workflow al fine di comprendere a fondo come coordinare...
Al compleanno di UGI parlando di “Services UI Composition” ho sottolineato un dettaglio che a pensarci bene è di una banalità disarmante, banalità che a volte è meglio ripetersi un paio di volte di troppo al fine di evitare fantasmagorici castelli di carta, o come dicono i francesi “seghe mentali” :-) In DDD esiste il concetto di Ownership, in SOA esiste il concetto di Ownership, quando si parla di sistemi di messaggistica, Command e Pub/Sub, esiste il concetto di Ownership. Quando si parla di UI? silenzio… In realtà se ci pensiamo bene ogni volta...
Direi che ci siamo, dato il contesto che abbiamo ipotizzato i nostri attori sono i seguenti: Marketing Warehouse Sales Shipping Publishing La cosa importantissima che abbiamo identificato a questo punto, e che è la base fondante di un buon design, sono i rispettivi Owner dei vari modelli. Ognuno degli attori in gioco è responsabile di un pezzetto dell’informazione che vediamo stilizzata nella figura di cui sopra, e “Publishing” è responsabile non del tutto, come purtroppo...
Ci siamo lasciati con un primo tentativo che sebbene praticabile espone comunque il fianco ad sacco di potenziali magagne. Prendiamo la solita immagine che abbiamo usato usato fino ad ora e proviamo ad applicare sull’immagine delle etichette che rappresentano gli attori di cui abbiamo parlato nel post precedente, l’obiettivo di questo esercizio è trovare gli owner, trovare quindi quali porzioni dell’informazione che stiamo visualizzando sono gestite da chi. I nostri attori potrebbero essere i seguenti, potrebbero essercene di più o di meno ovviamente in base al contesto: Marketing Warehouse ...
Siamo partiti da questa immagine: Partendo dall’assioma che rappresenti un requisito espresso da uno stakeholder non tecnico, ad esempio un product owner o una porzione dell’information flow frutto di una analisi di user experience. Kudos a Luca che accoglie la sfida e ci prova: Io direi un ViewModel principale (che so ProductsViewModel) ed una serie di template in base a diversi fattori : origine dei dati, prospettive di evoluzione della UX, necessità di rendering, etc... È sbagliato? non necessariamente, è giusto? non necessariamente :-) dipende? non direi, diciamo...
Workshop 1 Anno 2016 - Introduzione a DotNetCore, Microservice e ServiceFabric Per la serie come potete mancare ad un evento del genere? DotNetLiguria organizza questa serata per (s)parlare di DotNetCore, Microservice, SOA, DDD, ServiceFabric e Docker. Ci si vede li?
A Napoli abbiamo parlato di “Services UI Composition” e per arrivare li siamo partiti dal problema che vogliamo risolvere problema inevitabilmente generato da una corretta implementazione dei dettami di SOA e DDD. Prima di tornare a parlare di “Services UI Composition”, argomento vastissimo e complesso, vorrei fare un escursus sul processo di modellazione che, se basato su DDD e SOA, porta a risultati che per alcuni possono essere inaspettati. Fate un favore a voi stessi dimenticatevi la tecnologia, evitate cioè di cercare immediatamente una soluzione tecnologica a tutto quello che diremo, è controproducente. Inoltre ricordatevi che cosa è un...
Secondo me il problema è tutto li e ruota attorno all’uso del singolare e il problema siamo sempre noi sviluppatori. Abbiamo parlato di bene e male ci siamo lasciati con una domanda, poco tempo fa abbiamo invece dettagliato che cosa sia un servizio. In quest’ultimo periodo mi rendo sempre più conto che quando sento parlare di architettura, applicata ad uno scenario reale, sento sempre parlare di una sola architettura, perché tendiamo a pensare all’applicazione, o peggio ancora al sistema, nel suo insieme. I bounded context di DDD, che possono essere per certi versi accumunati con i servizi di...
La parola Event in Event Sourcing e la stessa parola Event in pub/sub non hanno nulla a che spartire, sono per puro caso la stessa sequenza di 5 lettere. La definizione più bella che ho sentito di Event Sourcing è: Perfect in lock free domain models, in high contention domains. Un Domain Event: Non lascia il bounded context a cui appartiene l’aggregato che lo genera Se lo pensiamo in termini C# potrebbe essere tranquillamente una classe/interfaccia internal; È ricco di informazioni, ergo contiene...
O peggio…mi basta avere una classe che implementa l’interfaccia IAggregate, che espone una proprietà Id. DDD è filosofia prima di tutto, la tecnologia ci azzecca poco o nulla. Potremmo prendere il 90% di quello che ci dice DDD e applicarlo al mondo dell’organizzazione aziendale e funzionerebbe lo stesso. Quando approcciamo DDD dobbiamo dimenticarci di essere dei tecnici, dobbiamo smettere di fare l’immediato collegamento con “come lo implementeremo”, DDD è principalmente un processo di apprendimento, se saltiamo tutta la parte di apprendimento DDD non serve proprio ad un bel nulla, semplicemente complicherà in maniera colossale la parte tecnico/tecnologica del...
I due acronimi, DDD e CQRS, stanno troppo spesso nella stessa frase e sempre più spesso mi rendo conto che per le persone devono andare a braccetto: nulla di più sbagliato. DDD ha uno scopo, per certi versi molto filosofico e aulico, che gira intorno al concetto di comprensione e/o processo di apprendimento, DDD si prefigge di permetterci di disegnare un modello di dominio che sia il più fedele possibile al modello analitico che vogliamo maneggiare. Il modello analitico è frutto del processo di apprendimento, o di analisi, che una serie di attori, i domain expert(s) (notare il...
Qualche tempo fa con un amico si stava discutendo di `Repository Pattern` e di tutto quello che gli gira intorno, tutta la disquisizione ruotava intorno a quale fosse il ruolo di un `repository` in un mondo orientato a CQRS. Siamo dopo un po’ di scambi di opinioni giunti alle seguenti questa conclusioni. Un repository deve consentire di caricare un aggregato data la sua chiave primaria; consentire di aggiungere una nuova istanza di un aggregato; persistere le modifiche apportate ad un aggregato; rappresentare una...
Ora che //BUILD ha ufficialmente sdoganato anche in casa Microsoft due concetti fondamentali come Microservices e DevOps è definitivamente giunto il momento di capire come far si che le nostre architetture siano adeguate, pronte e/o adeguabili a questo nuovo mondo che si sta spalancando davanti ai nostri occhi. Quello dei microservices è ad oggi un mondo alquanto fumoso, c’è ancora molta discussione su cosa sia un microservice, se in questa confusione ci mettiamo pure tanta nuova tecnologia, una su tutte Docker, che sta per invadere, o ha già invaso le nostre macchine, le cose si fanno ancora più complicate....
Vi ricordate quando da piccoli giocavate, e magari come me lo fate ancora :-), con il LEGO? Nel 2009 dicevo, quotando me stesso: Se modelliamo il nostro mondo in tanti piccoli, magari molto piccoli e molto tanti…, componenti che collaborano otteniamo un modello complesso, probabilmente molto complesso, ma facilmente testabile, manutenibile, evolvibile, etc… Al tempo il concetto era molto più in linea con il single responsibility principle che con le architetture distribuite ma se oggi mettiamo insieme quel concetto con le potenzialità offerte da una metafora come il LEGO e troviamo qualcosa che...
La serie di post su CQRS si arricchisce sempre più, ne mancano un paio per chiudere il cerchio e avere una overview abbastanza completa su “cosa”, “come” e “quando”. L’ultima volta che ne abbiamo parlato abbiamo introdotto il concetto di de-normalizzazione asincrona, elencando più o meno una lista di possibili passi simile a quella che segue: Invio del comando in POST; Ricezione del comando e dispatch dello stesso su una coda; Invio della risposta HTTP-202; Ricezione del comando e...
Nelle nostre divagazioni su CQRS di qualche tempo fa abbiamo parlato di eventualmente consistente ma non ci siamo addentrati nelle implicazioni tecniche che eventualmente consistente porta con se. Qualche, più di qualche, divagazione tecnica la approfondisco sul mio blog in inglese parlando di Jason che è un toolkit che ho scritto per eliminare dai pensieri dello sviluppatore tutta la parte infrastrutturale. In uno scenario come il seguente però abbiamo un piccolo problema nel momento in cui la parte di de-normalizzazione è asincrona: Supponendo una Single Page Application in cui i comandi arrivano via HTTP avete il...
Ai Community Days di quest’anno abbiamo sproloquiato di scalabilità, una delle cose su cui ho cercato di insistere è che per poter parlare di scalabilità è necessario in primis essere in grado di misurare e definire quali sono i requisiti che devono essere rispettati. Questo per un semplicissimo motivo: la scalabilità infinita è un mito, fine, è il requisito che ci deve far scegliere come scalare e non la semplice necessità di scalare. Facciamo un esempio banale e un po’ astratto per capire: Abbiamo un bel sito web di e-commerce, piccolo piccolo che fa...
Qualche giorno fa sono stato da un cliente per una giornata di consulenza, giornata che in partenza sembrava prospettarsi come la solita, senza nessuna connotazione negativa sia chiaro, giornata in cui si discute di tecnologia, ma mai aspettativa fu più sbagliata. La giornata partiva con l'obiettivo di capire come migrare un'architettura tradizionale, quindi basata su layer, verso un'architettura esagonale corredata da CQRS e Event Sourcing, partendo dal presupposto che il team si era già fatto tutta una serie di domande, sacrosante, che aprivano a molti dubbi sulla scelta che si stava per fare. n.d.r.: il...
...e le conseguenti pessime decisioni di design. Sto lavorando con le API di amministrazione dell’ACS di Windows Azure, API che sono esposte oltre che dal portale di Azure con una bella e comoda interfaccia anche come servizi in modo da poter programmaticamente gestire la configurazione. I servizi che l’ACS di Azure espone sono basati su OData (almeno in apparenza) ed espongono un modello apparentemente molto comodo, sempre in apparenza :-) Osservate il seguente stralcio di codice: var client = CreateManagementServiceClient();
var parties = client.RelyingParties;
foreach ( var party in parties )
{
Console.WriteLine(...
Perché DDD fa così fatica a prendere piede? Perché ogni volta che parli con qualcuno di DDD, o CQRS o EventSourcing, il discorso cade sempre sul "...e ma è costoso..."? IMHO Siamo ottusi, manager in cima alla lista (fate il vostro, facciamo il nostro, mea culpa). Da tecnici quali siamo la mostra mente è inevitabilmente deviata e pensiamo immediatamente alle implicazioni tecnico/tecnologiche che le scelte progettuali/architetturali portano con se. Peccato che come al solito abbiamo letto il manuale delle istruzioni a pezzi, saltando qua e là, comprendendo poco o nulla della visione d'insieme. Visione...
Ultimamente mi ritrovo spesso ad osservare mia moglie mentre ha a che fare, dovrei dire combatte, con del software, dovrei dire con del software pietoso. L'unica vera conclusione che posso trarre è che complessivamente scriviamo del software che definire anche solo accettabile è quantomeno stupido e senza senso. Nella stragrande maggioranza dei casi, usando anche software (web o meno che sia) blasonato fa molta fatica a raggiungere gli obiettivi che si è prefissata, siano essi un acquisto online o la semplice stampa di un documento PDF. Cercando di essere il più obiettivi possibili e partendo dal presupposto...
C’era una volta la velleità di avere il mega-sistemone che facesse tutto, velleità rapidamente abbandonata al crescere del monolite per ovvi motivi. Nel tentativo di realizzare il monolite ci si scontra molto rapidamente con il fatto che tipicamente i requisiti di business cambiano più rapidamente del tempo necessario per la realizzazione, ci si scontra con il fatto che non è possibile pensare di fare il deploy del monolite bloccando ogni volta tutta l’infrastruttura, ci si scontra con il dettaglio che non è possibile far evolvere indipendentemente le varie parti del monolite. Tutto questo, e molto altro, ci fa dire...
Tutte le volte che mi capita di parlare con qualcuno di CQRS o di sentire qualcuno parlare di CQRS ho la sensazione che ci si concentri troppo su quella che a mio modo di vedere è la parte meno importante tra le due componenti: i comandi; portare l’architettura verso un modello basato su comandi è fondamentale, sia chiaro, perché ci aiuta a modellare in maniera estremamente più semplice il modello mentale dell’utente, cosa che ci consente di fare un balzo in avanti eccezionale, ma i comandi sono anche la novità del momento e la “C” di CQRS sta oscurando quella...
Qualche giorno fa in “C come CQRS” abbiamo analizzato, senza scendere troppo nel dettaglio, una possibile implementazione della parte di comandi di CQRS. Ora, quello che abbiamo ricade a tutti gli effetti sotto il cappello dei tecnicismi, che, sono si importanti, ma senza avere una visione generale del problema trovano il tempo che trovano. Se ci spostiamo un pelo più in alto e diamo uno sguardo al tutto quello che vediamo, generalizzando molto e prendendo la letteratura alla lettera, è questo: Ci sono tante implementazioni possibili, anche molto più semplici di quella identificata nel diagramma,...
CQRS che…? per una esaustiva introduzione a CQRS potete leggere questo articolo di Martin Fowler. Andrea nella sua sessione su CQRS al .NETCAMPUS presentando il pattern, e una possibile implementazione, ha detto una cosa importantissima, particolarmente vera quando si parla in generale di Domain Driven Design: CQRS, Event Sourcing e DDD sono una metodologia di sviluppo che aggrega vari pattern architetturali, ognuno dei quali, in fase di implementazione, può essere declinato in modi diversi tutte egualmente giusti, in dipendenza del contesto in cui ci troviamo. (non sono le esatte parole, ma rendono...
(per una introduzione decisamente esaustiva a CQRS e Event Sourcing vi rimando all’articolo di Gianluca per UGIdotNET.) In un mondo basato su CQRS ed Event Sourcing in cui tutto è pensato per poter scalare orizzontalmente (ne parleremo approfonditamente in un altro post) nulla vi impedisce di passare da un modello di questo genere: Ad uno di questo genere: o, per certi versi ancora peggio ma per moltissimi ancora meglio, ad uno di questo genere: il problema è molto sensato che il gestore dell’evento, quindi nel nostro esempio il de-normalizzatore,...
Settimana scorsa Alessandro e il sottoscritto sono stati ad Ancona per una piacevolissima giornata in compagnia degli amici di dotNetMarche, a cui ovviamente vanno tutti i ringraziamenti del caso per l’organizzazione, la splendida accoglienza e le degne mangiate. Ok, tutto bello ma perché ci siamo stati? La giornata è stata l’occasione per analizzare come alcune delle funzionalità più interessanti di Windows Azure siano la manna dal cielo quando ci troviamo a sviluppare un’applicazione basata su CQRS e Event Sourcing, abbiamo visto quanto sia facile sfruttare la potenza messaci a disposizione da Service Bus, Worker e Web Role. ...
Un mesetto fa ho avuto l’onore di partecipare, in qualità di speaker, ai Community Days 2013. L’evento è stato un successo, ma su questo, vista la qualità dell’agenda e l’impeccabilità dell’organizzazione, non è che avessi molti dubbi e io mi sono decisamente divertito (s)parlando di sviluppo di applicazioni Windows 8 calate in un contesto più ampio, un contesto in cui l’applicazione ModernUI è uno dei tanti modi per accedere all’infrastruttura “enterprise” della nostra/vostra realtà. L’obiettivo più ampio era portare avanti il discorso iniziato da Andrea il giorno prima con l’introduzione a CQRS, in versione semplificata, dimostrando come DDD, CQRS...