Alberto Acerbis
Passionate dev, Microsoft MVP, author, learner
Passionate dev, Microsoft MVP, author, learner
Brescia, Italy
Actions
I am a lifelong learner, driven by the endless nature of technology. While I primarily define myself as a backend developer, I’m not afraid to explore the frontend when needed. For me, software development is about solving business problems and delivering value to customers, where Domain-Driven Design (DDD) patterns play a crucial role. I work as a software engineer at Intré, a company that shares this philosophy. As an introvert, stepping into the spotlight doesn’t come naturally to me, but I’m passionate about stepping outside my comfort zone to share what I’ve learned and continuously grow. I’m active in the tech community, contributing where I can, and co-founded the DDD Open and Polenta and Deploy communities. I’m also an active member of Blazor Developer Italiani and other groups. Additionally, I am an Microsoft MVP, a Azure Solution Architect and Azure IoT Developer.
Sono fondamentalmente un eterno studente, perchè la materia di studio è infinita. Mi sono sempre definito uno sviluppatore backend, ma non disdegno di curiosare anche dall'altra parte del codice. Mi piace pensare che 'scrivere' software significhi soprattutto risolvere problemi di business e fornire valore al cliente, e in questo trovo che i pattern DDD siano di grande aiuto. Lavoro come software engineer presso Intré, un'azienda che sposa questa ideologia; da buon introverso, trovo difficile uscire allo scoperto, ma mi piace uscire dalla mia comfort zone per condividere con gli altri le cose che ho imparato, in modo da trovare ogni volta gli stimoli giusti per continuare a migliorare. Mi piace frequentare il mondo della comunità, contribuendo, quando posso, con proposte attive. Sono co-fondatore delle comunità DDD Open e Polenta e Deploy, e membro attivo di altre comunità come Blazor Developer Italiani.
Sono un MVP Microsoft, un Azure Solution Architect e Azure IoT Developer.
Awards
Area of Expertise
Babbo Natale teme il Chaos e vuole Monitorare le sue Applicazioni
Babbo Natale sa che deve tenere sotto controllo i suoi sistemi se viole essere certo di poter consegnare tutti i regali in tempo. Per questo motivo ha chiesto agli Elfi di aggiornarli e di trovare il modo di renderli più robusti. I poveri Elfi hanno trovato prima una soluzione abbastanza articolata, ma funzionante, ma poi hanno scoperto che il Team di .NET ha trovato la soluzione facile per loro ... anche se hanno già un'applicazione funzionante e deployata! Quale? Beh, è una sorpresa
DDD e CQRS in salsa .NET 20 anni dopo
Sono passati vent'anni dall'uscita dalla nascita di Domain-Driven Design, un approccio domain-centrico al problema dello sviluppo del software. Nel suo iconico libro E. Evans parla di pattern strategici e pattern tattici.
I primi sono fondamentali per impostare adeguatamente l'architettura della nostra applicazione, i secondi per realizzarla.
A corollario del lavoro di Evans, pochi anni dopo l'uscita del libro, Greg Young ha introdotto un pattern destinato a cambiare il modo di sviluppare le nostre applicazioni, almeno alcune di esse, CQRS.
Attorno a questo pattern sono nate alcune convinzioni non esattamente veritiere, come ad esempio "Non posso applicare CQRS senza EventSourcing", siete sicuri?
Domain-Driven Design può convivere con CQRS, ma può farne a meno.
CQRS può convivere con EventSourcing, ma può farne a meno.
Vediamo come con esempi in .NET
Data Mesh: aka DDD in the data world
Siamo tutti affamati di dati. Ne abbiamo bisogno per alimentare i nostri modelli di ML, per mantenere dashboard e per fornire statististiche sempre più accurate. L'attuale gestione di questi dati però scricchiola, è in affanno, serve un nuovo approccio. I Datawarehouse, con le rigide regole di accesso, ci impediscono di scalare facilmente e velocemente come vorremmo. Come risolviamo il problema?
Possiamo aspettarci un contributo da DDD?
Data Mesh è un paradigma sociotecnico decentralizzato che tratta i dati come un prodotto, considera i domini come una preoccupazione primaria, applica il pensiero della piattaforma per creare un'infrastruttura di dati self-service e introduce un modello computazionale federato di governance dei dati.
Sei sicuro di conoscere Azure ServiceBus?
Lo sviluppo di sistemi distribuiti implica necessariamente la comunicazione fra i diversi componenti della nostra architettura.
Azure ServiceBus è sicuramente uno strumento potente, ma sappiamo sfruttare al meglio una coda? Ed un topic?
Dobbiamo creare code e topic manualmente, o possiamo delegare il compito alla nostra applicazione?
Come possiamo essere certi che il nostro codice non invii un evento su una coda ed un comando su un topic?
Un Muflone ci aiuterà nell'arduo compito!
Dimostrami che usi Azure ServiceBus senza dirmi che usi Azure ServiceBus
Lo sviluppo di sistemi distribuiti implica necessariamente la comunicazione fra i diversi componenti della nostra architettura. Abbiamo bisogno di conoscere diversi broker, il loro funzionamento e la loro configurazione; dobbiamo sapere che differenza c'è fra una queue ed un topic, cosa spedire su una queue e cosa pubblicare su un topic, ad esempio. Soprattutto dobbiamo essere sicuri di non inviare messaggi su una coda, quando andrebbero inviati su un topic, e viceversa.
Ed infine, abbiamo bisogno di passare da un broker in locale, per test e sviluppo, ad un broker in cloud per la produzione ... come sopravviviamo? Astraendo ovviamente!
Who fear the saga?
Saga: a long story of heroic achievement.
This is why sagas are often perceived like a complicate piece of software.
How does it works? How many types we can choose from? How much business logic it is allowed inside?
In this workshop we will discover that it is not that complicated to create one, we will build one from scratch and discover how we can apply specification by example to test its behaviors.
Bounded Context is not Enough!
When we consider to create a distributed system, frequently we use Bounded Contexts to handle specific business functions within clearly defined boundaries.
But is this enough? What about the static dependencies that each microservice has with the database or the servicebus or even with the frontend?
In this workshop we will explore the concept of Architectural Quantum (an independently deployable component with high functional cohesion) and how it can help us to create a distributed system with a clear separation of concerns.
Join us to discover a way to implement this architectural solution.
Tackling Chaos, Resilence & Metrics in the heart of your Application
Con la diffusione dei microservizi e delle architetture cloud distribuite, il web è diventato sempre più complesso. Tutti noi dipendiamo da questi sistemi più che mai, eppure i bug sono diventati molto più difficili da prevedere.
Il Chaos Engineering è un approccio disciplinato per identificare i bug prima che diventino vere e proprie interuzioni di servizio. Ma come si testa la risposta di un sistema sotto stress per identificare, e prevenire, le debolezze? Recentemente .NET ha messo a disposizione, direttamente nel framework, tutto il necessario per implementare esperimenti di Chaos nel codice. Vediamo come.
Tackling Chaos, Resilence & Metrics in the heart of your Application
In a world made of distributed services, where communication among them is a fundamental part of our application's functioning, it is crucial to increase the resilience of our applications. Distributed systems are inherently more complex than monolithic ones. It's difficult to predict all the ways they might fail, just think about the "eight fallacies of distributed systems". Chaos Engineering is a practice that aims to help us improve our systems, teaching us new things about their functioning under pressure conditions. There are several tools that support us in this area, but finally, we have everything available directly in the .NET framework. Let's see how to leverage it.
In this workshop we will get our hands dirty creating an API we will go querying injecting Chaos in the system to see how to insert resilience in our applications
Design Patterns for Distributed Systems
Distribuire applicazioni tramite Azure comporta un radicale cambiamento nell'approccio della progettazione. Tool come Aspire, o Dapr, ci facilitano certamente la vita, ma nel Cloud è importante sapersi muovere in autonomia. Le sfide principali da affrontare sono il Data Management, il Design and Implementation e ovviamente il Messaging. Il data Management rappresenta una delle chiavi fondamentali in un'applicazione cloud, in quanto i nostri dati saranno distribuiti su più fonti. Questo comporta una progettazione ed un'implementazione che deve affrontare sfide come coerenza e consistenza, il tutto passando dalle code di Azure per garantire basso accoppiamento fra i servizi. Facciamo il punto e vediamo come implementare un sistema simile
Una Saga salverà il Natale?
Come ogni anno il Babbo più famoso della storia è alle prese con i regali di Natale.
Deve orchestrare tutte le operazioni necessarie affinchè nessun bambino sia escluso.
Catalogare le letterine, raggrupparle, verificare la bontà dei bambini che le hanno inviate, caricare la slitta e preparare le renne per la consegna.
Riuscirà la nostra Saga ad aiutarlo ad orchestrare il tutto e salvare il Natale?
Eventually oppure Prima o Poi?
Nei Sistemi Distribuiti è frequente implementare la Eventually Consistent, ossia una persistenza dei dati certa, ma non in tempo reale. La paura principale in questi casi è "siamo sicuri che il dato si aggiornerà?". Il timore arriva un pò dal termine "Eventually", male interpretato da molti di noi. Vediamo in dettaglio cosa significa veramente Eventually Consistent e come possiamo implementare un sistema distribuito che sfrutta questo tipo di consistenza. Quali sono i vantaggi e, ovviamente, gli svantaggi.
Bounded Context is not Enough!
When we consider to create a distributed system, frequently we use Bounded Contexts to handle specific business functions within clearly defined boundaries.
But is this enough? What about the static dependencies that each microservice has with the database or the servicebus or even with the frontend?
In this workshop we will explore the concept of Architectural Quantum (an independently deployable component with high functional cohesion) and how it can help us to create a distributed system with a clear separation of concerns.
Join us to discover a way to implement this architectural solution.
Blazor in Distributed Systems
Quando lavoriamo su sistemi distribuiti basati su eventi uno dei problemi che ci troviamo ad affrontare è l'aggiornamento della UI quando nel nostro backend riceviamo un evento. Una soluzione definitiva, ovviamente, non esiste, dobbiamo sempre valutare tutti i possibili trade-off prima di prendere una decisione, ma signalR è una buona soluzione, semplice da utilizzare se la comunicazione passa attraverso un Hub, un pò meno se devo comunicare con i client al di fuori dell'Hub stesso. Vediamo come possiamo sfruttare signalR per queste situazioni.
Blazor e i Long Running Process
Una delle scelte che siamo chiamati a fare quando lavoriamo su sistemi distribuiti, sia che si tratti di una soluzione a moduli, sia che si tratti di una soluzione a microservizi, è la gestione dei workflow. La scelta definitiva, ovviamente, non esiste, dobbiamo sempre valutare tutti i possibili trade-off prima di prendere una soluzione. Per esempio, come gestiamo la nostra UI in Blazor durante una Saga? Come avvisiamo gli utenti di ciò che sta succedendo?
Bounded Context is not Enough!
Correva l'anno 2003 ed E.Evans ci presentò il suo iconico blue-book. Uno dei pattern più citati, soprattutto per la realizzazione delle architetture a microservizi, è il Bounded Context. Nel 1986 un altro articolo scosse il mondo, Fred Brooks pubblicò No Silver Bullet. Cos'hanno a che fare queste due pubblicazioni così distanti fra loro? E perchè ne parliamo ora, nel 2023? Venite alla mia sessione e ve lo spiegherò.
Evolutionary Architectures con .NET e Azure
Ci troviamo spesso davanti a progetti che nascono piccoli e crescono velocemente.
All’inizio di un nuovo progetto, spesso ci chiediamo: la metafora fra l'architettura software e l'architettura di un edificio è ancora valida? Siamo sicuri che l'architettura non possa evolvere così come evolvono le specifiche di un’applicazione?
Evolutionary Architectures è rivolto a coloro che si sono trovati a dover dare una direzione ai propri progetti e si sono posti queste domande.
Vedremo infatti che è possibile creare una architettura pronta ad evolversi, con esempi pratici che verrano poi rilasciati su Kubernetes (AKS) attraverso Azure Dev Ops, Helm e Github.
Modular Architectures con .NET
Per scrivere codice pulito, con responsabilità isolate, dobbiamo necessariamente implementare un'archietettura a microservizi? Dobbiamo portarci a casa tutta una serie di complessità sin dall'inizio del progetto? Esiste un'alternativa che ci permetta di scalare a progetto avviato?
Modular Architecture ha radici ben più profonde di quanto si possa immaginare, ed unisce il meglio delle due soluzioni alternative, monolite e microservizi.
Vediamo com'è possibile realizzare una soluzione simile in .NET
Using .NET Core to build and deploy microservices architecture
We have released our beautiful monolith on the server in the customer's cellar, but now we need to scale up.
First of all we have to design our monolith in a right way, so will be easy to split it.
Now new features come to implement and more traffic to handle. How do we solve the problem? Our monolith needs to be broken into many microservices that K8s is ready to host. But how will all these microservices talk to each other now? How we can introduce event communication in our microservice's architecture? Let's find out together
Tutti gli eventi sono testabili!
È davvero così difficile testare un dominio basato sugli eventi?
In questa sessione impareremo a scrivere test che convalidino il comportamento del dominio, andando oltre il classico approccio TDD. Ci concentreremo sulla validazione del cambiamento di stato del dominio durante il suo ciclo di vita.
Affronteremo il problema utilizzando specification testing e vedremo come questo supporta pienamente lo sviluppo di un dominio complesso ed in continua evoluzione.
BDD in Blazor using SpecFlow
Given-When-Then è uno stile di rappresentazione dei test o, come direbbero i suoi sostenitori, di specificazione del comportamento di un sistema usando SpecificationByExample.
Daniel Terhorst-North e Chris Matts lo hanno sviluppato come parte del Behavior-Driven Development. Dopo averlo adottato per il backend, mi sono chiesto se potesse essere utile anche per il frontend. Curiosi di sapere com'è andata? Scopriamolo insieme
DDD incontra i Dati (aka Data Mesh)
Siamo tutti affamati di dati. Ne abbiamo bisogno per alimentare i nostri modelli di ML, per mantenere dashboard e per fornire statististiche sempre più accurate. L'attuale gestione di questi dati però scricchiola, è in affanno, serve un nuovo approccio. I Datawarehouse, con le rigide regole di accesso, ci impediscono di scalare facilmente e velocemente come vorremmo. Come risolviamo il problema?
Possiamo aspettarci un contributo da DDD?
Data Mesh è un paradigma sociotecnico decentralizzato che tratta i dati come un prodotto, considera i domini come una preoccupazione primaria, applica il pensiero della piattaforma per creare un'infrastruttura di dati self-service e introduce un modello computazionale federato di governance dei dati.
Affoghiamo i microservizi nella birra
Partendo da uno scenario di un birrificio piccolino e con pochi ordini, mostreremo come la soluzione monolite è in grado di consegnare valore. Dopodiché dimostreremo come un monolite rilasciato sul server in cantina, se fatto bene, può scalare in maniera agile in una architettura a microservizi su kubernetes con helm.
Using .NET and Azure to build and deploy microservices architecture
Si parla tanto di microservizi, anche quando non sono strettamente necessari. Sono l'unica alternativa possibile per scrivere codice pulito, a componenti indipendenti e facilmente divisibile? E se costruissimo una soluzione a moduli? Attenzione, ogni modulo deve essere indipendente, dalla business logic ai dati, ma il tutto in un'unica soluzione. Molto più facili da testare, rispetto ai microservizi; meno infrastruttura da gestire, ma allo stesso tempo, pronti a scalare.
Scopriamolo insieme come .NET Core ci permette di creare soluzioni simili e come Azure sia pronta ad ospitarle
All events are testable!
Is it really that difficult to test an event-based domain?
In this session we will write tests that validate domain behavior, going beyond the classic TDD approach.
We will try to address the problem through specification testing and we will see how this fully supports the development of a complex and evolving domain.
Testiamo gli eventi
Vi è mai capitato di dover testare un sistema ad eventi? In questo caso il classico approccio TDD può essere utile? Oppure servirebbe uno strumento di testing diverso, più appropriato? Scopriamo insieme, con tanti esempi e tanto codice, ed una libreria open source, come preparare un adeguato ambiente di test adatto a questo tipo di soluzione.
Test non convenzionale nello sviluppo di microservizi con CQRS ed Event-Sourcing
Lo scopo è quello di realizzare un'applicazione composta da due microservizi che sottoscrivono gli stessi eventi. Utilizzeremo CQRS ed Event Sourcing e vedremo in particolare come testiamo gli eventi tralasciando il classico unit testing in favore dell'event specification testing.
Ovvero test più espressivi, che riprendano i termini utilizzati nell'Event Storming, quindi che utilizzano l'Ubiquitous Language e siano comprensibili anche ai Business Expert.
Perchè WebAssembly
WebAssembly non è più una tecnologia emergente, è una tecnologia presente nei nostri framework. Con .NET7 abbiamo assistito all'introduzione di molte novità provenienti proprio da Wasm, codice C# eseguito in JavaScript e codice JavaScript eseguito in C#, tanto per cominciare. Vediamo insieme cos'altro ci dobbiamo aspettare
DDD in salsa Cloud con Blazor e MinimalAPI
Delle MinimalApi si è detto di tutto e di più, ma forse possiamo ancora parlarne. Blazor è il framework per SPA che sta spopolando fra gli sviluppatori .NET. DDD è l'eterna promessa che stenta a diventare realtà ... oppure è l'ingrediente necessario per applicazioni veramente scalabili? Lo scopriremo insieme analizzando un'applicazione Blazor a microfrontend che utilizza le MinimalApi come backend a microservizi
DDD in pratica: i pattern per passare dal monolite ai micro servizi
Partendo da un event storming, che faremo insieme, vedremo una via per spaccare il monolite in micro servizi utilizzando domain drive design, cqrs ed event sourcing. Lo faremo tramite esercizi da svolgere insieme ed in gruppi e vedremo quali pattern del DDD si prestano per tale compito
DDD anche nei Dati?
Siamo a un punto di svolta nel settore dei dati, in cui le nostre soluzioni di gestione dei dati non sono più all'altezza della complessità delle organizzazioni, della proliferazione delle fonti di dati e della portata delle nostre aspirazioni di ottenere valore dai dati con l'intelligenza artificiale e l'analisi.
Data Mesh è un paradigma sociotecnico decentralizzato chetratta i dati come un prodotto, considera i domini come una preoccupazione primaria, applica il pensiero della piattaforma per creare un'infrastruttura di dati self-service e introduce un modello computazionale federato di governance dei dati.
Ma il contributo di DDD? Lo scopriremo insieme.
Babbo Natale e le letterine scritte in linguaggi diversi
Come ogni anno Babbo Natale è alle prese con migliaia di letterine scritte in linguaggi diversi, ognuna delle quali necessita di un traduttore, o di un compilatore, diverso, per essere interpretata.
Il rischio è quello di non essere in grado di leggerle tutte, di tralasciare quelle scritte in linguaggi non interpretabili dai suoi moderni strumenti di ricezione.
Per sua fortuna la soluzione è arrivata giusto in tempo. A lui basta prendere tutte le letterine e passarle al setaccio tramite WebAssembly.
Sarà vero che finalmente abbiamo trovato l'esperanto dei linguaggi? Scopriamolo insieme e vediamo di capire cos'è e cosa fa WebAssembly.
XmasDev 2024 Sessionize Event Upcoming
WPC 2024 Sessionize Event
Data Saturday Parma 2024 Sessionize Event
KanDDDinsky 2024 Sessionize Event
Azure Day Torino 2024 Sessionize Event
XE One Day - Rethink application Sessionize Event
ABP Dotnet Conference 2024 Sessionize Event
Global Azure Torino 2024 Sessionize Event
BlazorConf 2024 Sessionize Event
Explore DDD 2024 Sessionize Event
Codegen 2024 Sessionize Event
.NET Conf 2023 1nn0va Sessionize Event
XmasDev 2023 Sessionize Event
DevOpsHeroes 2023 Sessionize Event
Azure Day Torino 2023 Sessionize Event
1nn0va Saturday 2023 Sessionize Event
WeAreDevelopers World Congress 2023 Sessionize Event
Working Software 2023 Sessionize Event
Agile Venture Pordenone 2023 Sessionize Event
Domain-Driven Design Europe 2023 Sessionize Event
BlazorConf 2023 User group Sessionize Event
Global Azure Torino 2023 Sessionize Event
datasaturdays.com Pordenone 2023 Sessionize Event
Codegen 2023 Sessionize Event
.NET Conf 2022 1nn0va Sessionize Event
XmasDev 2022 Sessionize Event
Italian Agile Days 2022 Sessionize Event
1nn0va Saturday 2022 Sessionize Event
Working Software Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top