I read a bit about DDD but never really went in-depth with it, like I never read the book or anything.
Instead I just try to absorb the major takeaways that I got from what I've read:
1. Bring in people with domain knowledge to help you understand the expected behavior of the system.
2. Try to establish a consistent language that is used in both verbal conversations as well as code.
I feel like those are good, easy-to-understand principles, and I've never understood why the whole DDD space is taken up by this insanely complicated terminology and theory. It's so off-putting.
This is exactly spot on and my go-to approach as well. I always thought myself of a huge fan of DDD, simply because I think it makes so much sense to discuss the architecture directly with the stakeholders until everyone technical and nontechnical alike really agrees about the existence, relation and constraints of entities: By using common, ubiquitous language and just giving the same things the same consistent, common-sense names while giving different things different names.
It's a godsend for the top-down inside-out approach of requirements engineering that I like and teach.
Then I met some people the actual local DDD meetup group and was shocked that that part basically made up effectively zero percent of their discussion and the rest was taken up by talk about adapters, hexagonal architecture and all kinds of artificial design patterns that cultivate complexity and self-importance. I've been careful to call myself a DDD advocate ever since.
IMHO DDD went through the same unfortunate descent that Agile did: An originally really great idea and common-sense approach that went on to get bastardized into a cargo cult by coaches who like to produce sheets for BS bingo.
I also had the unfortunate experience of working with some die-hards who believe DDD dictates that "the code and only the code should reflect the business requirements 1:1", with emphasis on the "only". Which means that things that are often configurable in other systems are instead hardcoded and scattered in the codebase done by those. In early stage startups this is a death kneel.
Instead I just try to absorb the major takeaways that I got from what I've read:
1. Bring in people with domain knowledge to help you understand the expected behavior of the system.
2. Try to establish a consistent language that is used in both verbal conversations as well as code.
I feel like those are good, easy-to-understand principles, and I've never understood why the whole DDD space is taken up by this insanely complicated terminology and theory. It's so off-putting.