[aliasxneo]

I'm not "formally" trained in software engineering and am primarily self-taught. This area, in particular, has been confusing to me over the years, especially after consuming so many contradictory blog posts.

I tried to model DDD in a recent Golang project and am mostly unhappy with the result. Perhaps in my eagerness, I fell into the trap of premature abstraction, but there's not anything in particular that I can point to that might lead to that conclusion. It just feels like the overall code base is more challenging to read and has a ton of indirection. The feeling is made worse when I consider how much extra time I spent trying to be authentic in implementing it.

Now, I'm starting a new project, and I'm left in this uncertain state, not knowing what to do. Is there a fine balance? How is it achieved? I appreciate the author's attempt at bringing clarity, but I honestly walked away feeling even more confident that I don't understand how this all works out.

[marcosdumay]

The one point of DDD is that you make a dictionary of all of the domain terms and get everybody to accept them.

You can cut those 4 pages and throw the rest of the book away. But it is one of the best books on software engineering, and only gets better once you do that.

[RaftPeople]

> I'm not "formally" trained in software engineering and am primarily self-taught

Welcome to the club and I wouldn't be too worried about it (but definitely read and learn what others have figured out).

Software design and development is still an unsolved problem. The industry has not collectively found a foundational set of standard practices that apply across the board other than some of the most basic (e.g. organization is good).

You can tell that it's not solved by the relentless flow of industry trends that become the new "best practice" until some years later when we figure out "well, that approach has these pros and these cons and tends to fit with these types of problems, but definitely not a silver bullet, let's try the next thing"

Regarding your specific issue on your new project: just be pragmatic, get it working and learn from your decisions, it's all just a collection of pros and cons and the analysis of pro vs con changes depending on the angle you look at it (e.g. short term vs long term, slow changing environment vs fast changing environment, cost to value ratio, etc., etc., etc.)