Is domain driven design and clean architecture always a good idea? In my case, we are working on a project with ~100k LOC built with the Adonis.js framework, and we are refactoring the project with CA and DDD and I feel we are going to fight the framework on this
I would argue that DDD is something you always do as long as you name your abstractions to mirror the business terms of your system. Clean architecture is just a flavour of an architecture. It is not an industry standard and can be safely ignored in favour of something else. If you are using a opinionated framework the path of least resistance is to work within it. It is worth asking if the framework fits your needs before going heavy in to it but once the choice is made you will be better off.
Re Adonis and (Martin’s) Clean architecture, I think it’s fairly closely aligned out of the box. Controllers are, well, controllers, validated params define the DTOs which act as Use Case Input Port, your “use cases” and “gateways” can be organised as injectable services in the IoC container (it’s really a distinction of how exposed to the outside world they are I guess), and your entities are sort of handled by the ORM. As Fredrik says I wouldn’t stray too far from the framework.
Is domain driven design and clean architecture always a good idea? In my case, we are working on a project with ~100k LOC built with the Adonis.js framework, and we are refactoring the project with CA and DDD and I feel we are going to fight the framework on this
I would argue that DDD is something you always do as long as you name your abstractions to mirror the business terms of your system.
Clean architecture is just a flavour of an architecture. It is not an industry standard and can be safely ignored in favour of something else. If you are using a opinionated framework the path of least resistance is to work within it. It is worth asking if the framework fits your needs before going heavy in to it but once the choice is made you will be better off.
Re Adonis and (Martin’s) Clean architecture, I think it’s fairly closely aligned out of the box. Controllers are, well, controllers, validated params define the DTOs which act as Use Case Input Port, your “use cases” and “gateways” can be organised as injectable services in the IoC container (it’s really a distinction of how exposed to the outside world they are I guess), and your entities are sort of handled by the ORM.
As Fredrik says I wouldn’t stray too far from the framework.