+1 for the Matthias Noback book, although I do not agree with everything in the book (personal preferences etc..), still it is a good read especially if you are just starting out with getting some order in your code.. @stevescruz the folder structure presented seems like it fits just one bounded context and at a larger scale it will get messy. Something that has been in use for quite some time in the DDD community is the Application/Domain/Infrastructure groupings by BC. That way you have clear separation between them and if you are starting with a monolith it is quite easy to move to microservices since the code is already logically grouped across your future service boundaries. Here is a quick example of what a single folder looks like:
You are right, I can view more clearly the domain and the infrastructure groups, but sometimes I lose sight of the application group.
Thanks for sharing this file structure, it is very organized. I love seeing how other people structure things.
Where do you store your routes (I imagine in the web folder at infrastructure)? and your controllers and why?
Controllers are part of the infrastructure layer so, Infrastructure/Web is where all the web related stuff sits. Console is for console commands (still in Infrastructure). Routes on the other hand exist in an independent file just for routes (not a big fan of annotations), dependencies are defined in a separate file too, which aggregates the different dependency providers for each BC or module. I use PHP (no framework) but I think this approach is language agnostic.
Sorry for reviving this thread, but I've just found out your suggested DDD folder structure and it is pretty interesting!
I was separating application, domain and infrastructure inside my src folder, but your approach is way cleaner.
I just have a simple question, where do you store abstract interfaces? For example, I have a bunch of abstract classes that I use inside all my layers, in which folder would you store those?
Just to be clear, those abstractions are used by basically all my aggregates. For example, I have an "DomainAggregateService" abstract class, which is basically some global methods that every aggregate service has.
I'm thinking to give it a shot to your suggestion, and placing it in something like lib/... or something like that (while my aggregates would be inside src, since I'm using Javascript and it is pretty common to place source code inside src folder)
Abstract classes like AggregateRoot, AggregateRootCollection and interfaces like DomainEvent / Listeners etc are defined in a composer package that is imported in the project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing your point of view on how to apply DDD in real projects, very useful reading.
I've also found it very inspiring to read this book by Matthias Noback:
matthiasnoback.nl/book/advanced-we...
The book goes deep into the idea of separating core (domain) code from infrastructure, with a lot of real code examples.
It uses PHP examples but the concepts can be applied in general.
I did not know this book. Thanks for sharing Alessandro, I'll definitely check it out.
+1 for the Matthias Noback book, although I do not agree with everything in the book (personal preferences etc..), still it is a good read especially if you are just starting out with getting some order in your code..
@stevescruz the folder structure presented seems like it fits just one bounded context and at a larger scale it will get messy. Something that has been in use for quite some time in the DDD community is the Application/Domain/Infrastructure groupings by BC. That way you have clear separation between them and if you are starting with a monolith it is quite easy to move to microservices since the code is already logically grouped across your future service boundaries. Here is a quick example of what a single folder looks like:
You are right, I can view more clearly the domain and the infrastructure groups, but sometimes I lose sight of the application group.
Thanks for sharing this file structure, it is very organized. I love seeing how other people structure things.
Where do you store your routes (I imagine in the web folder at infrastructure)? and your controllers and why?
Controllers are part of the infrastructure layer so, Infrastructure/Web is where all the web related stuff sits. Console is for console commands (still in Infrastructure). Routes on the other hand exist in an independent file just for routes (not a big fan of annotations), dependencies are defined in a separate file too, which aggregates the different dependency providers for each BC or module. I use PHP (no framework) but I think this approach is language agnostic.
Sorry for reviving this thread, but I've just found out your suggested DDD folder structure and it is pretty interesting!
I was separating application, domain and infrastructure inside my src folder, but your approach is way cleaner.
I just have a simple question, where do you store abstract interfaces? For example, I have a bunch of abstract classes that I use inside all my layers, in which folder would you store those?
Just to be clear, those abstractions are used by basically all my aggregates. For example, I have an "DomainAggregateService" abstract class, which is basically some global methods that every aggregate service has.
I'm thinking to give it a shot to your suggestion, and placing it in something like
lib/...or something like that (while my aggregates would be insidesrc, since I'm using Javascript and it is pretty common to place source code inside src folder)Abstract classes like AggregateRoot, AggregateRootCollection and interfaces like DomainEvent / Listeners etc are defined in a composer package that is imported in the project.