The article focuses on project structure and layers like it is some stiff guideline for DDD whereas it is not.
DDD is about describing the domain in the code. Then building upon this domain code to create some useful use cases (also dropping in some infrastructural code for persistence, messaging and stuff like that). DDD is about direction of dependencies and direction of control in those mentioned "layers". About loosely coupled layers. It is about how your application can grow around the domain.
In application that follows DDD principles, I should be able to tell what is the application about just looking at the packages.. In application from the article I just know that this is another weekend application.
Great! Thanks Kskitek for the feedback. I'm no way close to perfection. I wrote about this based on how I implemented DDD for a small application I built(which the link is shared in the article).
To help me better understand, do you have any material, link, video, article, github repo, anything at all, that explained how DDD is implemented the "ideal" way in Golang? I and the rest of the people reading this article will greatly benefit.
I have to agree ksiktek here. I have a feeling you were a bit too quick with diving into the implementation. Although in the end the implementation is what it all comes down to, that is not the essence of DDD. Instead DDD is - as you mentioned, but not deepened further - about creating a design in such a way that it is
understandable for you as a software engineer (and your collegues)
understandable for your customers (that's something most other approaches don't)
brings the problem domain (your customer's world) and the solution domain (your world of code) together in one solution
In doing so, it removes some of the steps that 'traditional' software development took: first create a functional or conceptual design, then translate that into technical design and finally translate that into code. In each translation, information got filtered or lost, resulting in all the bugs and mismatches that we see nowadays between software as it was built and software as it was intended.
I've been teaching DDD courses for over 7 years now, and I will be posting short digestable articles about it over the coming months (transferring my training material to either Medium or Dev.to for those who can't attend - or want to revisit the material after the training). Feel free to dive in. If you drop me a message here or on twitter (@delphinocons
) I'll send you an invite for the newsletter that I'm launching related to these same articles. And of course, feel free to ask if you have specific questions. :-)
Hello Steven, you're welcome. The articles will be posted on Medium and here on Dev.to, so I'm sure you'll catch them. I also have a newsletter, which is released in lock step with the articles. If you subscribe to that you will get automatic notifications of new articles: eepurl.com/g1oOaD
This article makes a huge disservice to DDD.
The article focuses on project structure and layers like it is some stiff guideline for DDD whereas it is not.
DDD is about describing the domain in the code. Then building upon this domain code to create some useful use cases (also dropping in some infrastructural code for persistence, messaging and stuff like that). DDD is about direction of dependencies and direction of control in those mentioned "layers". About loosely coupled layers. It is about how your application can grow around the domain.
In application that follows DDD principles, I should be able to tell what is the application about just looking at the packages.. In application from the article I just know that this is another weekend application.
Great! Thanks Kskitek for the feedback. I'm no way close to perfection. I wrote about this based on how I implemented DDD for a small application I built(which the link is shared in the article).
To help me better understand, do you have any material, link, video, article, github repo, anything at all, that explained how DDD is implemented the "ideal" way in Golang? I and the rest of the people reading this article will greatly benefit.
Thanks as I anticipate your response.
Hey Steven,
I have to agree ksiktek here. I have a feeling you were a bit too quick with diving into the implementation. Although in the end the implementation is what it all comes down to, that is not the essence of DDD. Instead DDD is - as you mentioned, but not deepened further - about creating a design in such a way that it is
In doing so, it removes some of the steps that 'traditional' software development took: first create a functional or conceptual design, then translate that into technical design and finally translate that into code. In each translation, information got filtered or lost, resulting in all the bugs and mismatches that we see nowadays between software as it was built and software as it was intended.
I've been teaching DDD courses for over 7 years now, and I will be posting short digestable articles about it over the coming months (transferring my training material to either Medium or Dev.to for those who can't attend - or want to revisit the material after the training). Feel free to dive in. If you drop me a message here or on twitter (@delphinocons ) I'll send you an invite for the newsletter that I'm launching related to these same articles. And of course, feel free to ask if you have specific questions. :-)
Hi Angelo,
Thanks for your comment. I will really be looking forward to your posts as it will help me better understand DDD better.
I kindly request that you also share the link here when it is ready.
Thanks.
Hello Steven, you're welcome. The articles will be posted on Medium and here on Dev.to, so I'm sure you'll catch them. I also have a newsletter, which is released in lock step with the articles. If you subscribe to that you will get automatic notifications of new articles: eepurl.com/g1oOaD
great
Here's a new one :-)
dev.to/delphinocons/domain-driven-...