@bendix
I discussed the article with some co-workers yesterday, very interesting do see someone applying DDD to nestjs.
One thing while reading this, here is a quote that kept me curious
due to the project being unrestricted without clear boundaries, with a mess of spaghetti code for our server and API. We're talking about services that are 600+ LOC long.
In nestjs, they recommend organising your application components through modules. Ideally you would have multiple feature modules and each encapsulating it's own business-domain(shoppingcart -> entity, service, controller, spec and dto).
This something that they even state in nestjs docs
A feature module simply organizes code relevant for a specific feature, keeping code organized and establishing clear boundaries. This helps us manage complexity and develop with SOLID principles, especially as the size of the application and/or team grow.
You said the problem you and your team ran into was having too much code in the services file, was this the only drawback?
Hey @guledali
, ultimately it came down to poor handling in the early stages of the development. We had neglected to place strict boundaries around our domain logic so something like a user.service encapsulated a far too large chunk of user logic. We should've spilt the code out into further sub-modules to avoid this.
I think the suggested route recommended by Nest.js definitely works. We find following this DDD approach it keeps clear distinctions between all the different processes our server goes through. (endpoints, business/domain logic, data access etc) Whereas following the typical Angular structure it puts more emphasis on each microservice of your server.
I think there are positives and negatives to both.
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.
@bendix I discussed the article with some co-workers yesterday, very interesting do see someone applying DDD to nestjs.
One thing while reading this, here is a quote that kept me curious
In nestjs, they recommend organising your application components through modules. Ideally you would have multiple feature modules and each encapsulating it's own business-domain(shoppingcart -> entity, service, controller, spec and dto).
This something that they even state in nestjs docs
You said the problem you and your team ran into was having too much code in the services file, was this the only drawback?
Hey @guledali , ultimately it came down to poor handling in the early stages of the development. We had neglected to place strict boundaries around our domain logic so something like a
user.serviceencapsulated a far too large chunk of user logic. We should've spilt the code out into further sub-modules to avoid this.I think the suggested route recommended by Nest.js definitely works. We find following this DDD approach it keeps clear distinctions between all the different processes our server goes through. (endpoints, business/domain logic, data access etc) Whereas following the typical Angular structure it puts more emphasis on each microservice of your server.
I think there are positives and negatives to both.