Project Current File Structure
src folder
-config folder
-database folder
-errors folder
-middlewares folder
-models folder
-repos...
For further actions, you may consider blocking this person and/or reporting abuse
Good content, but I feel I must add something.
I totally agree that splitting files per type makes little sense. Developers deliver functionality and working on a certain feature should not require adding or changing files in twenty folders.
Concerning the infrastructure and dependencies, it, in fact, has little to do with DDD. Clean Architecture, ports and adapters, onion architecture and, in fact, software engineering is all about finding the right level of abstraction, building loosely-coupled and highly cohesive components.
Thank you for your contribution. It made me realize that I should emphasize more on determining context boundaries. That's another thing I like about DDD, the fact that it prioritizes using a set of language that translate business terms and complex ideas instead of overly technical language.
I especially like this quote I saw at Martin Fowler's website: "Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design."
Your last paragraph was perfect.
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.
+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:
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.
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.
I did not know this book. Thanks for sharing Alessandro, I'll definitely check it out.
I never did DDD, in my team we also.have the separation by filetype. but I tell my team they should develop the api in a way, that we could swop from graphql to http, socket or other protocol. That leads to have very small resolver/handler.
Do you have some opinion and thought using DDD in a microservice or monolithic architecture?
I do not have experience with monolithic architecture, only with microservices. I'd recommend using DDD in a microservice with your use case.
In my situation it allowed me to change from MongoDB to PostgreSQL without a hassle since the infrastructure layer was separate from the domain.
I use dependency injection to inject the repository implementation (infrastructure layer that is related to the database) onto my repositories and services (both part of the domain layer), so when I needed to change from MongoDB to PostgreSQL it was only necessary to change things in the infrastructure layer such as the repository implementation and some other minimal things like the database connection. In the end the repository and the services were unchanged.
So I strongly recommend you to use DDD with Dependency Injection and Liskov Substitution principle.
Show this to your colleagues: docs.microsoft.com/en-us/dotnet/ar...
For a monolith, it's especially useful, as it makes it easier to find what you're looking for when you have a lot of files.
For swapping between different third party libraries or protocols, Steve's answer is on point. Splitting infrastructure from the domain with a common interface / adapter will allow you to swap the inner workings of infrastructure without having to rip apart your domain layer.
That makes sense, because there are many massive sized monolithic codebases, so it's imperative to structure it in a manner to find things easier. Thanks for the tip Cole.
@stevescruz Here modules act as bounded context or same part of domain.
As I see in CreateAppointmentService
import IAppointmentsRepository from '@modules/appointments/repositories/IAppointmentsRepository';
import INotificationsRepository from '@modules/notifications/repositories/INotificationsRepository';
Is it ok to call different modules which act as the cross boundaries? I need to know without event driven how can we make cross boundary communication. Is it ok to duplicate code/entity for each domains/sub-domains?