loading...

re: Applying Domain-Driven Design principles to a Nest.js project VIEW POST

FULL DISCUSSION
 

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

Code of Conduct Report abuse