improving package names

[yagitatsu]

Thanks for creating this repository. Now, I am studying with this.
Especially, I felt interested in wrapping service.

var bs booking.Service
bs = booking.NewService(..)
bs = booking.NewLoggingService(...)

As far as I know, DDD has layerd architecture, but packages on this code is placed in flat.
When I develop golang web application, for example, I often write as below:

interfaces/booking/
interfaces/routing/
application/booking/
domain/cargo/
infrastructure/inmem/
infrastructure/mongo/
...

I think this is better, but what do you think?
I am happy if you check it out 😄

[marcusolsson]

I'm glad that you're finding the repository useful! Also, thank you for contributing with your thoughts and ideas to the project!

First off, DDD does not dictate how you structure your project. What's important in terms of the practice of DDD is that the business is the most important thing in your project and personally, I think the project structure should reflect this.

My personal opinion is that the structure you propose is more of a "Java/C#-thing" than a "DDD-thing". In Go, packages are not intended to be used for simply organizing code. Instead, they should be units of high cohesion that are named after what they provide, not what they contain. Think vertical layers rather than horizontal layers.

I briefly touch on this in my talk at GolangUK: https://youtu.be/twcDf_Y2gXY?t=1129

[yagitatsu]

Thanks for your quick reply !
I understood your thought. I will try it on my project and watch your movie 👍

However, I wonder if beginners of DDD are difficult to understand code which is placed like this repository 🤔

[marcusolsson]

I believe beginners of DDD should focus on exploring the business with the domain experts, discovering the importance of the ubiquitous language and then possibly even learning about bounded contexts and aggregate design. How the actual code looks like depends on the language you use, but the principles will still apply. For example, if you're using a functional programming language, many of the object-oriented patterns in Eric's book wouldn't make any sense. I think the ideas from DDD should work in harmony with the language/technology that has been chosen to do the job. Compare with Paul Rayner's Ruby port of the DDD sample app, which looks quite different from both the Go and Java versions because it's been adapted to the idioms and best practices for building Ruby on Rails applications.

I will leave this issue open for now so feel free to add any thoughts you might have.

[yagitatsu]

I am sorry for delay response.
Maybe, I do not understand "Go-thing".

In Go, packages are not intended to be used for simply organizing code. Instead, they should be units of high cohesion that are named after what they provide, not what they contain. Think vertical layers rather than horizontal layers.

I want to try this thought one day. After that, let me show my thought if I have some insights.