Introduzione al Domain Driven Design (DDD)DotNetMarche
In questa sessione si approfondirà il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una “forma-mentis” per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.
Defining the business value proposition of EA and PPM
Eliminating project risks
Accelerating project execution
Managing project and architecture inter-dependencies
Delivering realized value
Improving collaboration of Architecture and PMO
Building Business & IT Architecture Roadmaps with ArchiMate & TOGAFCorso
Building effective Business and IT Architecture Roadmaps and aligning your business strategy and IT capability with current and future-state architectures with ArchiMate and TOGAF.
Learn about:
• Transition planning
• Milestones with visual status
• Heatmaps and gap analysis
• Lifecycle states
• And more...
Corso webinar slides. Presented on Thursday 25th September 2014 by Larry Wallendorf, Global Pre-Sales Manager Enterprise Architecture at Corso.
Introduzione al Domain Driven Design (DDD)DotNetMarche
In questa sessione si approfondirà il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una “forma-mentis” per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.
Defining the business value proposition of EA and PPM
Eliminating project risks
Accelerating project execution
Managing project and architecture inter-dependencies
Delivering realized value
Improving collaboration of Architecture and PMO
Building Business & IT Architecture Roadmaps with ArchiMate & TOGAFCorso
Building effective Business and IT Architecture Roadmaps and aligning your business strategy and IT capability with current and future-state architectures with ArchiMate and TOGAF.
Learn about:
• Transition planning
• Milestones with visual status
• Heatmaps and gap analysis
• Lifecycle states
• And more...
Corso webinar slides. Presented on Thursday 25th September 2014 by Larry Wallendorf, Global Pre-Sales Manager Enterprise Architecture at Corso.
Personally designed (content + graphics design), officially accredited IQBBA® CFLBA (Certified Foundation Level Business Analyst) courseware.
Trademarks are properties of the holders, who are not affiliated with courseware author.
ScottMadden recently partnered with APQC for a complimentary three-part webinar series focused on shared services.
This webinar session, presented by Brad DeMent and Jerred Crosby, partners at ScottMadden, addressed employee engagement, continuous improvement, new service offerings, and expanding the scope of operations.
Guide pratique de la dématérialisation des factures fournisseurs 2014documalis
Un guide de découverte des techniques de dématérialisation des factures fournisseurs pour l'entreprise privée et l'administration dans le contexte PES V2, basé sur les bonnes pratiques des Workflows, de la GED et de la reconnaissance automatique de contenu via OCR, RAD et LAD.
Effective Application Portfolio Management using ArchiMateCorso
Learn how innovative organizations can manage and optimize the application portfolio, releasing time and costs for more strategic and valuable programs.
Take a high-level look into:
• Understanding the cost of your IT estate
• Analyzing the impact of change to an application in your portfolio
• Visualizing application and technology roadmaps for future decision making
• Identify overlaps and gaps in IT capabilities
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Equivalences and diffrences between SysML and Arcadia / CapellaObeo
Designing complex and critical systems requires a level of rigor in engineering practices that only formalized and tool-supported modeling approaches can provide.
The Arcadia / Capella solution embeds a methodological guidance that constitutes one of its most significant originalities and success factors. By lowering the learning curve for systems engineers, Capella is an enabler for large scale MBSE adoption.
Largely inspired from several industry standards, Arcadia / Capella simultaneously form an enrichment and a simplification of SysML: a large proportion of the core concepts of the Arcadia method are aligned on the SysML ones, and most SysML diagrams have twins in Capella.
In this webinar, we will:
- Show to which extent Arcadia / Capella can be considered as a “SysML-like” solution, by illustrating diagrams and concepts equivalences
- Present the main differences between SysML and Arcadia / Capella
and provide rationales
Technical Illustrations with NX CAD NPR supportMatthias Ahrens
How to utilize the non photorealistic rendering (NPR) mode of the embedded Lightworks Design Ltd. render engine in SIEMENS PLM NX CAD to generate source images for technical illustrations? Hint and tricks for the tool utilization resp. Artistic Image render option inside NX.
Data-Ed Slides: Best Practices in Data Stewardship (Technical)DATAVERSITY
In order to find value in your organization's data assets, heroic data stewards are tasked with saving the day- every single day! These heroes adhere to a data governance framework and work to ensure that data is: captured right the first time, validated through automated means, and integrated into business processes. Whether its data profiling or in depth root cause analysis, data stewards can be counted on to ensure the organization's mission critical data is reliable. In this webinar we will approach this framework, and punctuate important facets of a data steward’s role.
Learning Objectives:
- Understand the business need for a data governance framework
- Learn why embedded data quality principles are an important part of system/process design
- Identify opportunities to help drive your organization to a data driven culture
Five Cool Use Cases for the Spring Component in Oracle SOA SuiteGuido Schmutz
Both Oracle SOA Suite and Oracle Unified Business Process Management Suite make it possible to embed Java code as a Service Component Architecture (SCA) first-class citizen through the Spring component implementation type. Thereby the coarse-grained components of Oracle SOA Suite are extended by the much-finer-grained Spring beans wrapped inside the Spring component. This session presents five cool use cases for the Spring component. It shows how and why you would want to use the Spring component and will hopefully inspire attendees to use it for their own projects.
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
Lessons learned on collaborative modeling: how EventStorming survived, and helped us survive the pandemic. And how it evolved to support new collaboration paradigms.
Personally designed (content + graphics design), officially accredited IQBBA® CFLBA (Certified Foundation Level Business Analyst) courseware.
Trademarks are properties of the holders, who are not affiliated with courseware author.
ScottMadden recently partnered with APQC for a complimentary three-part webinar series focused on shared services.
This webinar session, presented by Brad DeMent and Jerred Crosby, partners at ScottMadden, addressed employee engagement, continuous improvement, new service offerings, and expanding the scope of operations.
Guide pratique de la dématérialisation des factures fournisseurs 2014documalis
Un guide de découverte des techniques de dématérialisation des factures fournisseurs pour l'entreprise privée et l'administration dans le contexte PES V2, basé sur les bonnes pratiques des Workflows, de la GED et de la reconnaissance automatique de contenu via OCR, RAD et LAD.
Effective Application Portfolio Management using ArchiMateCorso
Learn how innovative organizations can manage and optimize the application portfolio, releasing time and costs for more strategic and valuable programs.
Take a high-level look into:
• Understanding the cost of your IT estate
• Analyzing the impact of change to an application in your portfolio
• Visualizing application and technology roadmaps for future decision making
• Identify overlaps and gaps in IT capabilities
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Equivalences and diffrences between SysML and Arcadia / CapellaObeo
Designing complex and critical systems requires a level of rigor in engineering practices that only formalized and tool-supported modeling approaches can provide.
The Arcadia / Capella solution embeds a methodological guidance that constitutes one of its most significant originalities and success factors. By lowering the learning curve for systems engineers, Capella is an enabler for large scale MBSE adoption.
Largely inspired from several industry standards, Arcadia / Capella simultaneously form an enrichment and a simplification of SysML: a large proportion of the core concepts of the Arcadia method are aligned on the SysML ones, and most SysML diagrams have twins in Capella.
In this webinar, we will:
- Show to which extent Arcadia / Capella can be considered as a “SysML-like” solution, by illustrating diagrams and concepts equivalences
- Present the main differences between SysML and Arcadia / Capella
and provide rationales
Technical Illustrations with NX CAD NPR supportMatthias Ahrens
How to utilize the non photorealistic rendering (NPR) mode of the embedded Lightworks Design Ltd. render engine in SIEMENS PLM NX CAD to generate source images for technical illustrations? Hint and tricks for the tool utilization resp. Artistic Image render option inside NX.
Data-Ed Slides: Best Practices in Data Stewardship (Technical)DATAVERSITY
In order to find value in your organization's data assets, heroic data stewards are tasked with saving the day- every single day! These heroes adhere to a data governance framework and work to ensure that data is: captured right the first time, validated through automated means, and integrated into business processes. Whether its data profiling or in depth root cause analysis, data stewards can be counted on to ensure the organization's mission critical data is reliable. In this webinar we will approach this framework, and punctuate important facets of a data steward’s role.
Learning Objectives:
- Understand the business need for a data governance framework
- Learn why embedded data quality principles are an important part of system/process design
- Identify opportunities to help drive your organization to a data driven culture
Five Cool Use Cases for the Spring Component in Oracle SOA SuiteGuido Schmutz
Both Oracle SOA Suite and Oracle Unified Business Process Management Suite make it possible to embed Java code as a Service Component Architecture (SCA) first-class citizen through the Spring component implementation type. Thereby the coarse-grained components of Oracle SOA Suite are extended by the much-finer-grained Spring beans wrapped inside the Spring component. This session presents five cool use cases for the Spring component. It shows how and why you would want to use the Spring component and will hopefully inspire attendees to use it for their own projects.
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
Lessons learned on collaborative modeling: how EventStorming survived, and helped us survive the pandemic. And how it evolved to support new collaboration paradigms.
EventStorming was born as a massively in-person workshop to discover and model complex businesses and design event-driven software. But the old ways are no longer viable. After one year of experiments and discoveries in a forced-remote setting we know a lot more about what is still working and what is not.
What happens when you have the luxury of leading software projects without trade-offs and you're a Domain-Driven Design fanatic? You start stretching DDD concepts until it hurts and make experiments un uncharted territory.
In this talk, we'll see a few unconventional approached to Context Mapping and what happens when you fully embrace CQRS and Small Aggregates as a modeling paradigm.
Can software architecture affect the culture and emotions in the workplace? In this talk I look to some ways architectural choices shape collaboration and survivability in the workplace.
Software design as a cooperative game with EventStormingAlberto Brandolini
You got the stickies and the paper roll, and possibly already run a large Big Picture workshop to highlight where the problem is. Now you're in a room with business, software and UX experts hungry for a solution.
How do you make the magic happen?
In this talk, we'll explore some strategies about how to deliver with collaborative modeling, and how to narrow the gap between stickies and working code.
I've spent the last years modelling complex businesses and Software Architectures with EventStorming. The original recipe evolved a lot from the initial one. This is EventStorming state of the art.
Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.
Too often we model processes around the myth of Database Transactions, ofter forgetting what a transaction really means in the real world. This talk shows an easy and cheap approach to use together with EventStorming in order to include User Experience into process modelling
Most software development processes are focused on tracking and delivery. Unfortunately, writing code is no longer the bottleneck. The real bottleneck is the team ability to learn about the domain complexity and do the right thing.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Using EventStorming to drill into domain modelling complexity: from the big picture into the design of aggregates, processes and read models. A different approach to enterprise software modelling.
Software development is not one size fits all. Domain-Driven Design is significant where there's high complexity and high value. In these areas different tools might be needed. EventStorming is the best way I know to gather requirements in a complex environment, and also maps with CQRS/ES architecture perfectly.
There are some recurring themes in Domain-Driven Design applications, and distant domains show more similarities that differences, especially when you start taking into account peculiarities of specific Bounded Contexts. This is where a different type of design could happen.
Put the key stakeholders in the same room with an unlimited modelling surface, and some tricks, and you'll end up not only with a viable model, but also with skeleton for continuous improvement.
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.