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.