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...
Full Domain Driven Design Archive