Blog
So You Wanna Be a DDD Practitioner - Talysson Oliveira's Roadmap for Getting Started
Posted on 2026-09-14 - 4 minute read
Talysson Oliveira, software architect and chief learning officer at Brazilian software boutique Codeminer42, opened his DDD Europe talk by naming the misconceptions he hears most often: that DDD only adds complexity, that it's really just a way to organise files and folders, that it requires a pile of design patterns, or the classic, "I never needed DDD for my software to work." His talk, "So You Wanna Be a DDD Practitioner," is a deliberately unrushed walk through what DDD actually is, before it ever touches code.
Stop relating DDD to code, for now
Oliveira's opening ask is blunt: for the next part of the talk, forget what you know about DDD and stop connecting it to code entirely. His starting point is Eric Evans's own definition, that the heart of software is its ability to solve domain-related problems for the user. From there, he builds up the vocabulary carefully: a domain is the broad field an application touches (finance, healthcare, logistics), a model is the small, deliberately incomplete slice of that domain a project actually needs, and the ubiquitous language is what emerges once domain experts and technical people converge on the same words for the same things.
The point he keeps returning to is that a model and its ubiquitous language are never universal across a whole company. The word "customer" means something different to a sales team, a shipping team, and a billing team, even when they're all technically talking about the same person. That's what bounded context actually names: the boundary within which a given model and vocabulary are valid and unambiguous, not a technical construct, but a communication one.
Strategic design before tactical design
Only after laying this groundwork does Oliveira turn to code, walking through entities, value objects, aggregates, repositories, and domain services with concrete TypeScript examples built around a car sales domain. But he's explicit that this tactical layer only makes sense downstream of the strategic work: model-driven design, in his framing, is simply the part of DDD concerned with code decisions, decisions that should always trace back to the model the team has already built together.
His domain service explanation is a useful corrective on its own: don't default to creating a service every time something doesn't obviously belong to an entity. Use it as a last resort, once you've genuinely ruled out that the responsibility belongs somewhere else.
A reading path, not just a reading list
The talk closes with what amounts to a sequenced curriculum: avoid "DDD-lite" entirely, start with the shorter distilled books before attempting the blue book or Vlad Khononov's Learning Domain-Driven Design, and deliberately allow frustration into the learning process rather than reaching for AI tools to shortcut it. Only once the fundamentals are solid does he recommend moving on to Vaughn Vernon's Implementing Domain-Driven Design, event sourcing and CQRS, and Susanne Kaiser's Architecture for Flow.
It's a talk aimed squarely at people who've felt intimidated by DDD's reputation for complexity, and its core message is reassuring: most of that complexity is optional, or at least comes later. What's not optional is talking to people.
What particpants said:
Very nice and clear, well-structured, easy to follow talk. It anchored DDD concepts firmly for me.
This talk was a good popularisation about DDD which is inspiring for new joiners.