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?
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.
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.
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?
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.
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...