Hi Chisomo,

really appreciate the kind words, glad it resonated.

You’re asking the right question, and also a slightly dangerous one 🙂. That's because it’s tempting to answer it with a reading list, while the thing you’re trying to learn is not primarily learned from books.

Domain modelling is much closer to a craft (like pottery, or architecture) than it is to something you can absorb passively. Books can give you vocabulary and examples, but the actual skill develops when you try to structure something yourself and feel where it resists.

That said, a few things are worth reading, just not in the way people usually recommend them:

Domain-Driven Design: Tackling Complexity in the Heart of Software — mainly for the idea of ubiquitous language. That chapter is foundational. The rest is useful as reference, but I wouldn’t try to “apply DDD” as a method. Design Patterns: Elements of Reusable Object-Oriented Software — not because patterns make you a good modeller, but because they give you a vocabulary for expressing structure once you start seeing it. The Mythical Man-Month — older, but still one of the clearest explanations of why conceptual integrity matters.

More important than reading is how you approach your day-to-day work. A few practical starting points:

Try to avoid “fat services” that orchestrate everything. Ask yourself: which object actually owns this behaviour? Then move it there. Let objects own both state and behaviour. If something has behaviour but no state, that’s fine — it can still be an object that owns that responsibility. When something feels awkward to implement, don’t immediately work around it. Treat that friction as a signal that your model might be off.

If you want something more hands-on, there’s an old exercise that still works surprisingly well: take a simple domain (orders, invoices, etc.), assign each concept to a person (or even just objects on a table), and “play through” a scenario. Each participant is only allowed to act within their responsibility. It sounds simplistic, but it forces you to think about boundaries in a very concrete way.

The goal at this stage isn’t to “do DDD correctly”. It’s to start noticing the difference between:

putting code where it’s needed, and putting behaviour where it actually belongs.

Once you see that difference, you’ll start seeing it everywhere.

If this way of thinking clicks for you, I write more about it here as well: https://blog.leonpennings.com It’s essentially an extension of the same ideas from the article, just explored from different angles.

The real question is whether better tooling / future AI will close this “understanding gap.” I believe the answer depends on the scale of the application:

For small, relatively simple applications (roughly up to 20-30 user stories), tooling and current AI can already replace most traditional development. The domain is shallow enough that deep modeling isn’t critical. For larger, long-lived enterprise systems, I don’t think better tooling alone will be enough. The gap isn’t just a matter of more context or better prompts. Building a good domain model requires imagination, conceptual invention, and iterative discovery through friction, the very process that current AI architectures bypass. AI generates structure quickly, but it doesn’t hold intent or accumulate nuanced understanding the way evolutionary modeling does.

Until AI can actively perform real domain modeling (discovering natural concepts, responsibilities, and boundaries), the most effective approach remains strong human engineering judgment paired with AI as a powerful accelerator for implementation. So yes, tooling helps a lot. But it hasn’t replaced engineering in complex domains, and I’m not convinced it will anytime soon.

For smaller applications, AI can often handle the full cycle effectively. For larger, long-lived systems, though, a coherent domain model and deep context become critical. In the evolutionary modelling approach, building the code is the learning process. The friction, the failed attempts, the moments when a concept doesn’t fit, these aren’t obstacles. They are the essential feedback mechanism that refines your understanding of the domain. The code becomes both the map and the territory. AI breaks that loop. It’s like having someone else read War and Peace for you and then giving you a detailed summary. You might grasp the broad plot, the Napoleonic wars, the fates of Pierre, Natasha, and Andrei, but you miss the emotional depth, the evolving character arcs, the philosophical layers, and the subtle interconnections that give the story its real power. In small applications, those nuances often don’t matter much. In complex systems, they are everything. The accumulated understanding of why things exist, how responsibilities truly relate, and how the domain behaves under pressure lives in those details. When you outsource the building, you also outsource the learning. That’s why the 85%; the structuring, naming, and boundary finding, cannot be fully delegated. It’s not just design. It’s domain acquisition through the act of building.

The “code as learning” point resonates. AI gives you the result, but skips the iterations that normally shape your understanding. That tradeoff is fine for small systems, but becomes risky as complexity grows.