Tech Excellence

Last time, we showed how EventStorming, DDD, and Clean Architecture can help us foster shared mental models between domain experts and developers effectively. This time, we will focus on one main variation of EventStorming, Design-Level EventStorming, to demonstrate how we can effectively employ it during iteration planning to split user stories and derive business rules and aggregates, such that we can then use the EventStorming diagram to directly create test cases for Test-Driven Development.

We will then demonstrate how to test-drive an aggregate from no code to existence using TDD in baby-steps. In this coding part of the session, besides iterating on basic TDD tools like the rule of 3, fake it, obvious implementation with transformation priority premise (TPP), triangulation, or ZOMBIES, we will also demonstrate how software design is done in the refactoring phase and show how refactoring tools like “Parallel Change” can effectively, and safely, replace code structures like single with multiple values in baby-steps, without breaking any code, nor breaking tests, in the process.

This session focuses on integrating various tools and techniques to effectively develop software from story to implementation within an agile, domain-focused context.

ABOUT OLIVER

Oliver is a technical agile coach, technical trainer, and software engineer that promotes, teaches and coaches on DDD, XP, refactoring, Ports & Adapters (and its variations) and other related agile software development topics.

Many products start out with a simple, naive model able to prove market fit. And most of the time that one model grows, because more features need to be put in at a fast pace. This can have a huge impact once the product needs to scale. Because that fast pace can turn the model into a Big Ball of Mud, and most of the time that model isn’t the most useful model to solve the core business problems anymore. Everyone in the team knows we need to change that Big Ball of Mud, but we also don’t want to close shop. We want to keep adding features to attract more customers, scale the product and turn into a profitable product. So how can we both get ourselves out of the Big Ball of Mud while also scaling the product?

In this talk, I will tell the story of how our software development team decoupled their Big Ball of Mud, to several bounded contexts all within the same monolith. I present several heuristics, practices, tools and a strategy to decouple the current model while continuously adding features to the product and gaining feedback from the customers. One of the bigger challenges was that the team had no knowledge of Domain-Driven Design, and I will show you how the team with their stakeholders started embracing DDD. Ending up with a strategy to disentangle the model, an idealised bounded context design and monitoring domain events from the bounded context that drove collaboratively drives the product roadmap.

Outline of the session:

- Introduction of the use case, it’s domain and the challenge
- Domain-Driven Design 101
- Why understanding the underlying needs was crucial
- Collaborative software design and embedding software architecture in the teams
- From output to data-driven outcomes through Domain-Driven Design

ABOUT KENNY

I believe in collaborative software design where ‘every voice shapes the software’. Leveraging a domain-driven design approach with Team Topologies, I facilitate clearer communication between stakeholders and software creators by collaborative modelling and deep democracy, decoding complexities, resolving conflicts and ensuring software remains agile to business demands.

TECH EXCELLENCE CONFERENCE 2024 - ONLINE

EUROPE SESSIONS: