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


Afternoon chaps, @guledali , @maxhampton . I've just uploaded an example repository here. Hope it covers enough of your interest, please hit me with more questions if you've got them.

FYI that repo isn't prod ready, you will need to spend some time tweaking passport and mongoose to get the DB working. Figured it would suffice but happy to expand it further if you want :)


Thanks Harry, the repository is definitely interesting to browse through, and clears up some of my confusion. It's leading me down the road of looking into options for interface injection in Nest.

Kind of a follow up question, I still see the domain layer taking on dependencies from higher levels, namely the UserRepositoryModule. Is this mainly to get around dependency injection limitations?

I'm not a stickler for 100% pure DDD, the code is still very well segmented. I am curious, though, if this is a concession your team made and the rationale behind bringing a persistence layer dependency into the domain layer. Did you consider alternate approaches to keep the Domain layer dependency free?


Hey Max, so it turns you actually can do interface injection (somewhat) with Nest.js.

A lovely fellow on the GitHub repo submitted a PR detailing just that:


I will update the blog post when I get a chance.


Hey Max. When we started this process we looked into interface injection but we came up short. For us to have any communication with our persistence layer we had to introduce the user repository dependency into the UserModule.

We decided that our domain layer would:

  1. Be free of all third-party code
  2. Would only accept the relevant domain model as a param or a return type from the persistence layer

We figured this was adequate for our needs.

Do let me know how you get on and if you are able to overcome this.

Code of Conduct Report abuse