--- title: "Comment by Chisomo Chiweza on \"AI can build anything except an understanding of what you are building\" | Hashnode" description: "Good day. I am a programmer just starting out in my career (nearing 3 years now including internships). I've seen the DDD label added to so many LinkedIn profil" url: "https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a" --- [Discussion](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1) Comment [AI can build anything except an understanding of what you are building](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1) [Chisomo Chiweza](https://hashnode.com/@mwprogrammer) [May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a) Good day. I am a programmer just starting out in my career (nearing 3 years now including internships). I've seen the DDD label added to so many LinkedIn profiles but never really wrapped my head around what it was conceptually or what problems it attempted to alleviate. Ironically, this was a beautiful introduction to the motivation behind domain modelling and why it matters when working on large software systems. I came to learn about the limitations of AI but left curious about this aspect of software engineering I know so little about. Was a delight to read. What literature do you recommend for individuals like me looking to begin exploring this type of thinking within their day to day programming work? It might be a bit too early in my career to consider formal approaches but at least philosophically, I could get started with having it shape how I approach my work. [Leon Pennings](https://hashnode.com/@leon74) [May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a#reply-69f9dbfca386d7f12181b638) 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](https://blog.leonpennings.com/) It’s essentially an extension of the same ideas from the article, just explored from different angles. [Chisomo Chiweza](https://hashnode.com/@mwprogrammer) [May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a#reply-69f9e7caa386d7f1218b9aa2) Thank you. Will be sure to check out the list and your blog too :)