← Graph

Might & Magic of Domain-Driven Design

talk 27 connections

Mateusz Nowak's wroclove.rb 2025 single-speaker talk. Frames DDD as 'might' (patterns/heuristics learned from books and talks) plus 'magic' (experience and intuition gained by practicing every day — even by modeling apps you use like Uber, and speculating about new features). Demonstrates a full application-design process on a Heroes of Might and Magic III creature-recruitment scenario: start with EventStorming (Alberto Brandolini) to harvest events with domain experts (available-creatures-changed, creature-recruited, creature-added-to-army, creatures-surrendered, combat-finished, etc.); identify business processes; then switch to Event Modeling (coined by Adam Dymitruk in 2018, originally 'single flow event storming') to draw processes like movie frames using commands (blue), events (orange), views (green), and properties — avoiding technical jargon like policies/aggregates. Uses the 'what happened before/after an event?' heuristic to find autonomous module boundaries (recruited creatures also join army, but surrendered creatures and battle outcomes also affect army — so those belong to separate modules joined only by an Automation). Explains slices: write slice (command→event), read slice (event→view), and automation slice (event→command), which enables parallel task-splitting for a team. Maps the model to code with three pure functions — decide (command + state → events), evolve (events → state), and react (event → command) — in a decider-style, persistence-agnostic Ruby sample that can be plugged into either event sourcing (events→evolve→state→decide→events) or snapshot storage (state→decide→events→evolve→state). Advocates translating given/when/then model specifications into tests, delegating the boilerplate to LLMs like ChatGPT. Ends by replacing code review with architecture review/execution during planning, citing modularity as a business capability (Heroes 5 duel mode shipped as a paid extension because the game was modular enough), and quoting 'it is not the expert's knowledge that is translated into code but the developer's understanding'. Closes with LinkedIn article series, QR code, and feedback survey.

date
2025-03-14
type
talk
code_language
Ruby
example_domain
Heroes of Might and Magic III — creature recruitment
talk Might & Magic of Domain-Driven Design
about
Central subject of the talk — DDD process and mindset shift.
talk Might & Magic of Domain-Driven Design
about
Event Modeling concept
Uses Event Modeling as the core modeling notation and process.
talk Might & Magic of Domain-Driven Design
about
EventStorming concept
Starts the design process with EventStorming big-picture and process-level sessions.
talk Might & Magic of Domain-Driven Design
about
Event Sourcing concept
Shows event sourcing composition of decide/evolve and the alternative snapshot storage.
talk Might & Magic of Domain-Driven Design
about
CQRS concept
Slicing write and read sides relies on CQRS for independent development.
talk Might & Magic of Domain-Driven Design
about
Decider Pattern concept
Implements domain logic with the decide/evolve/react decider functions.
talk Might & Magic of Domain-Driven Design
about
Introduces the automation pattern as the glue between autonomous modules.
talk Might & Magic of Domain-Driven Design
about
Vertical Slice concept
Splits team work along write, read and automation vertical slices.
talk Might & Magic of Domain-Driven Design
about
Saga Pattern concept
Mentions sagas as the standard way to implement long-running automations that consume multiple events.
talk Might & Magic of Domain-Driven Design
about
Opens by citing Eric Evans' blue book — first shown to the speaker during studies as a game changer.
talk Might & Magic of Domain-Driven Design
about
Eric Evans person
Credits Eric Evans as the author of the blue book that began his DDD journey.
talk Might & Magic of Domain-Driven Design
about
Credits Brandolini as author of EventStorming and its canonical book.
talk Might & Magic of Domain-Driven Design
about
Recommends Brandolini's book as reference for the EventStorming step.
talk Might & Magic of Domain-Driven Design
about
Adam Dymitruk person
Credits Adam Dymitruk with coining Event Modeling in 2018.
asked_at
Might & Magic of Domain-Driven Design talk
First audience question during Q&A.
asked_at
Might & Magic of Domain-Driven Design talk
Audience Q&A question about cart-total-style calculations.
asked_at
Might & Magic of Domain-Driven Design talk
Audience Q&A question about executing long-running automations.
person Mateusz Nowak
authored
Might & Magic of Domain-Driven Design talk
Delivered this talk at wroclove.rb 2025.
from_talk
Might & Magic of Domain-Driven Design talk
Recommendation given in the talk to build DDD intuition by modeling Uber and reacting to new features like Uber shipping.
from_talk
Might & Magic of Domain-Driven Design talk
Heuristic from the talk: ask what happens before/after an event to reveal module boundaries.
from_talk
Might & Magic of Domain-Driven Design talk
Closing proposal of the talk — shift quality work to planning and make code review a formality.
from_talk
Might & Magic of Domain-Driven Design talk
Argument made via the Heroes 5 duel-mode extension example — modularity enables new paid products.
from_talk
Might & Magic of Domain-Driven Design talk
Closing quote and thought that the talk leaves the audience with.
from_talk
Might & Magic of Domain-Driven Design talk
Mentioned while showing Ruby test skeletons generated from given/when/then specs.
talk Might & Magic of Domain-Driven Design
presented_at
Single-speaker talk at the 2025 edition of the conference.
related_to
Might & Magic of Domain-Driven Design talk
The talk explicitly follows up on Mateusz Nowak's 'Mat' talk earlier in the day.
related_to
Might & Magic of Domain-Driven Design talk
Follows up on Mateusz Nowak's talk where process managers were called automations.

Provenance

Created
2026-04-17 16:18 seed
Read by
31 extractions