Large scale software development projects often fail to deliver the expected value.
Release after release, the resulting stack becomes unsafe and harder to change. Even worse, the fragility of the existing system pollutes the ecosystem: relevant business requests might be procrastinated due to lack of safety, while good developers might be tempted to leave.
Domain-Driven Design attacks these problems from the source, by promoting a tighter alignment between business stakeholders and software practitioners, and a different approach for critical software development.
The class progressively shifts from general purpose into technical topics.
- Software Architect
- Software Developer
Program and Agenda
Day 1 – A different game
Domain Driven Design at the state of the art.
What matters now and why.
A different approach to software development: a new mindset makes DDD a perfect match for critical projects.
Exploring large and complex domain with Big Picture EventStorming.
See and touch how different subdomains cooperate and how a business-driven structure for the software infrastructure spontaneously emerge from stakeholders collaboration.
Strategic DDD: the big picture.
Where and when we should approach a complex software development process with Domain-Driven Design. Core Domain, Supporting e Generic Subdomains. Strategic Distillation.
Core Domain Strategies: managing collaboration between developers and other key stakeholders.
Debunking myths about the Domain Expert. DDD as an approach to software development process: ubiquitous language and Whirlpool model. How DDD meets Agile, Lean and Theory of Constraints.
Day 2 – System dynamics.
Discovery of the system’s behavioural model.
Using Design-Level EventStorming to model critical processes and understand stakeholders needs and motivation.
Managing Bounded Contexts: how to make multiple models co-evolve and cooperate, without trade-offs that we’ll one day regret.
Brownfield Context Mapping: how to quickly read the implementation scenario, and how to choose the best strategies to lead implementation. Context Mapping Patterns. Reading organisations structures and limitations.
Greenfield Context Mapping: strategies to manage models of growing complexity. Why, when and how to split our models. The three archetypes and their implementing patterns.
Day 3 – Architecture & software
Which architectures for DDD?
Different implementation approaches: DDD by-the-book, Hexagonal (AKA ports and adapters), Event Sourcing and CQRS. How does it match with current software architecture paradigms?
Evolution of different implementation strategies since 2004. Which are the best strategies given our current technology stack?
Event Driven Modelling: modelling a complex architecture outside-in.
Patterns for discovery and modelling of a Domain Events based system.
Modelling our way out of the legacy: how common flaws in past approaches to modelling paved the way to repeatable strategies for large system refractoriness in the sweet spot.
Q & A: topic marketplace on the hottest topics, managed in a Kanban fashion.