Hi Steven, thank you for the article, there is not much DDD articles so this is good thing.
However, I have some observations regarding implementation details.
1) You start by "DDD comprises of 4 Layers" Domain, Infrastructure, Application, Interfaces then ... You put Infrastructure inside Domain ! Infrastructure package should be on the same level as Domain, Application and Interfaces. That is because Infrastructure layer brings support to all 3 others layers, not only domain. You can define go service interface inside your application package then have its implementation inside infrastructure because the implementation brings some weird dependencies.
2) packages "utils" :S in DDD you should not have an "utils" package. Everything have a place.
Auth and Security are infrastructure stuff
Middleware and FileUpload are Interfaces stuff
3) You talk about Entities but not about Agregates, you separate Repositories from Entities, their should be colocated in the same package , the "agregate" which name should be the aggregate name. Modularity is a big principle of DDD. Interchangeable component losely coupled with big cohesion.
4) In food_app.go in the application layer, there is a Service Interface , good. But there is no Factory for it, the struct implementation is just public to everyone "type FoodApp struct{...}" , it should be private and be called something like "type foodService struct {}" Factories are important because they help construct the object (inject services if needed, instrument it, etc )
5) The factory of your repository should
a) be inside the infrastructure package
func NewUserRepository(db *gorm.DB) repository.UserRepository
b) it takes an infrastructure object gorm.DB that the caller should not handle
6) You could use the DomainRegistry pattern to handle the restitution of the different factories (service, repo, aggregates). DomainRegistry interface in domain root then the DomainRegistry implementation in the infrastructure
In fact, there are other concerns but I think you get the point. Tactical patterns of DDD are direction to follow this is not strict if we respect certain rules.
Don't get me wrong this is just a fair critics. Because every one is learning, me the first. But from what I see the article can confuse first time DDD players because you break some principles.
If you want I can fork you repository and propose something we can discuss on.
For the first point, The Infrastructure Layer is actually on the same level as the Domain. This was not the case in the first push. It had long been corrected. Please check.
For the second point, I'm currently refactoring to have the Auth in the infrastructure(have been a bit busy at work), I will probably update before the week runs out.
For the third point, I will refactor to that. Thanks.
For the fourth point, that was an oversight. The change has been effected now.
For the fifth point, I didn't quite get you. But this no longer applies in the implementation above.
func NewUserRepository(db *gorm.DB) repository.UserRepository
The article is currently in a constant state of editing as constructive feedback such as yours are given. If you don't mind, can you elaborate on your fifth point?
Please go ahead and fork the repository, your changes are welcome.
Thanks again for the feedback.
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Hi Steven, thank you for the article, there is not much DDD articles so this is good thing.
However, I have some observations regarding implementation details.
1) You start by "DDD comprises of 4 Layers" Domain, Infrastructure, Application, Interfaces then ... You put Infrastructure inside Domain ! Infrastructure package should be on the same level as Domain, Application and Interfaces. That is because Infrastructure layer brings support to all 3 others layers, not only domain. You can define go service interface inside your application package then have its implementation inside infrastructure because the implementation brings some weird dependencies.
2) packages "utils" :S in DDD you should not have an "utils" package. Everything have a place.
Auth and Security are infrastructure stuff
Middleware and FileUpload are Interfaces stuff
3) You talk about Entities but not about Agregates, you separate Repositories from Entities, their should be colocated in the same package , the "agregate" which name should be the aggregate name. Modularity is a big principle of DDD. Interchangeable component losely coupled with big cohesion.
4) In food_app.go in the application layer, there is a Service Interface , good. But there is no Factory for it, the struct implementation is just public to everyone "type FoodApp struct{...}" , it should be private and be called something like "type foodService struct {}" Factories are important because they help construct the object (inject services if needed, instrument it, etc )
5) The factory of your repository should
a) be inside the infrastructure package
func NewUserRepository(db *gorm.DB) repository.UserRepository
b) it takes an infrastructure object gorm.DB that the caller should not handle
6) You could use the DomainRegistry pattern to handle the restitution of the different factories (service, repo, aggregates). DomainRegistry interface in domain root then the DomainRegistry implementation in the infrastructure
In fact, there are other concerns but I think you get the point. Tactical patterns of DDD are direction to follow this is not strict if we respect certain rules.
Don't get me wrong this is just a fair critics. Because every one is learning, me the first. But from what I see the article can confuse first time DDD players because you break some principles.
If you want I can fork you repository and propose something we can discuss on.
Great. Thanks, a lot Epo for the feedback.
For the first point, The Infrastructure Layer is actually on the same level as the Domain. This was not the case in the first push. It had long been corrected. Please check.
For the second point, I'm currently refactoring to have the Auth in the infrastructure(have been a bit busy at work), I will probably update before the week runs out.
For the third point, I will refactor to that. Thanks.
For the fourth point, that was an oversight. The change has been effected now.
For the fifth point, I didn't quite get you. But this no longer applies in the implementation above.
func NewUserRepository(db *gorm.DB) repository.UserRepository
The article is currently in a constant state of editing as constructive feedback such as yours are given. If you don't mind, can you elaborate on your fifth point?
Please go ahead and fork the repository, your changes are welcome.
Thanks again for the feedback.
damianopetrungaro.com/posts/ddd-us...
I think it's the best articles about DDD and Go.