Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong

Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level. When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt. At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains". Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.