You've read the book. You've watched the talks. You can recite the difference between an entity and a value object in your sleep. So why does your domain model still feel wrong the moment you try to build it?
The answer isn't that you need more theory. It's that understanding a concept and being able to do it are two entirely different skills, and only one of them improves with practice.
Where deliberate practice comes from
The term "deliberate practice" comes from psychologist Anders Ericsson, who spent decades studying how people become experts, in music, chess, sport, and surgery. His research, found something more specific and more useful than a simple hour count: not all practice is equal.
A violinist who plays through the same piece for years without correction doesn't improve much after the first year or two. A football player who works with a teacher, targets specific weaknesses, and gets immediate correction keeps improving for decades. The difference isn't time spent. It's the structure of that time.
Ericsson's studies of expert performers, from chess grandmasters to elite athletes, kept surfacing the same pattern: expertise comes from a specific kind of effortful, feedback-driven repetition, not from experience alone. Plenty of professionals with twenty years of experience are no better than they were after five, because doing your job on autopilot doesn't count as practice. It's just repetition.
What deliberate practice actually requires
Deliberate practice isn't "trying harder." It has a fairly specific shape, and if you strip out any of these elements, you lose most of the benefit.
A clear, specific goal. Not "get better at DDD," but "correctly identify the aggregate boundaries in this scenario" or "model this business rule as a specification rather than an if-statement buried in a service." Vague goals produce vague improvement.
Full concentration and effort. This is why deliberate practice is tiring. You're operating right at the edge of your current ability, not comfortably inside it. If a design exercise feels easy, it's probably not doing much for you.
Immediate, informative feedback. This is the piece most self-directed learners are missing. You can practise modelling all you like, but if nothing tells you where your model breaks down, you'll happily repeat the same mistakes with growing confidence. Feedback needs to come quickly enough, and be specific enough, to actually change what you do next.
Repetition with adjustment. You don't do the exercise once. You do it, get feedback, adjust, and do it again, closing in on the skill a little more each round. Growth comes from the loop, not from any single attempt.
This is also why reading about DDD patterns can only take you so far. You can understand exactly what an aggregate is supposed to do and still draw the wrong boundary the first, second, and fifth time you try it in a real domain. The gap between knowing and doing only closes with practice, and only if someone more experienced is there to tell you when you've got it wrong and why.
Where you get all four elements at once
This is precisely why we structured Domain-Driven Design in Your Favourite Language the way we did.
It would have been easier to build a training around slides and small isolated code samples. Instead, every session pairs new theory with homework: you implement a working piece of a real domain-driven application, in your own language, at your own pace. That's the specific, effortful goal. You're not absorbing patterns in the abstract, you're deciding, this week, whether this business rule belongs in a specification or an entity, and living with the consequences in actual code.
The part that matters most, though, is what happens next. At the start of every following session, experienced DDD practitioners evaluate what you've built. Not a generic checklist, but direct feedback on your implementation, from people who've drawn these boundaries wrong themselves and learned to spot the same mistakes in someone else's code. You'll also get an example solution and the reasoning behind it, so you can compare your thinking to someone else's and see exactly where the two diverge.
Then you go again. New exercise, same loop: goal, effort, feedback, adjustment. Over six sessions, that loop is what turns "I understand tactical patterns" into "I can build a working domain model and defend every decision in it."
If you've been meaning to move from knowing DDD to actually doing it, this is the structure built for exactly that.
Check out upcoming sessions of DDD in Your Favourite Language.