I’m such a huge fan of DDD. IMO, if you only ever read one book on Software Architecture, that’s the one to pick. A key point, though, is that you learn the ri

I’m such a huge fan of DDD. IMO, if you only ever read one book on Software Architecture, that’s the one to pick. A key point, though, is that you learn the right domain models/abstractions over time. Refactoring is critical as you gain more insight into the domain. If you’re constantly questioning your modelling of the domain, and refactoring towards a better one, you’ll end up with a great model and thus a clean, understandable, easy to extend/modify system. If you stick with whatever abstractions you chose at the start, when you knew way less about the domain/business problems, you’ll likely end up with poor abstractions, and a code based that’s slow, tedious and error prone to modify. Convincing the business that it’s worth setting aside time to constantly refactor towards better domain models is often the hardest part, but crucial.