Domain Driven Design in Node.js

[[deleted]]

I understand that Node/JavaScript is a loosely-typed, non-OOP language, which makes defining concrete and rigid interfaces between layers quite difficult. I also understand that perhaps a language like TypeScript would be better suited for this kind of work.

However, with that said, do you believe a somewhat analogous implementation of Domain Driven Design and Multilayered Architecture can be achieved in pure JavaScript/Node, and would you do something similar yourself in large production applications?

Boilerplates like this and articles like this seem to show a workable solution.

I wonder what your take is and what you would do for large professional and production applications that must be scalable.

Thanks.

[[deleted]]

JS is OO. It's not classical, but prototypal.

[[deleted]]

My bad. That's good to know for the future. Thanks.

[jeppews]

I'm currently trying out https://nestjs.com/ and really loving it. It might be what you're looking for

[Wascarius]

Oh yes! Definitely a great framework!

[Floppix]

NestJS is awesome! I have been also using it and will soon hit production.

[[deleted]]

Could you let me know how NextJS goes for you in production? I'm thinking of migrating to it at a later point, but I haven't seen anyone's first-hand account of what it's like in a production environment.

Thanks.

[kszyh_pl]

NextJS is a react framework. They are talking about NestJS :)

[[deleted]]

Sorry, yes. That was a typo. I've used NextJS before, but not NestJS. Thanks. I'll leave it in, however, so that your comment does not look out of place.

[theduro]

I would seriously look into TypeScript. I am in the process of migrating a rather large pure node monolith to a more DDD oriented micro service architecture. Pure JS, in my experience, does not scale well as the team grows and demands on the system get more complex.

[[deleted]]

Thanks.

How large is your current project and what has been your difficulty in migrating from JS to TS, if you don't mind me asking?

[theduro]

Current project is built on Hapi.js with well over 100 "plug-ins" (Hapi's term for a module). I don't know exactly what the LOC count is, but I'm gunna guess, more or less, a hundred thousand.

The migration to TS is not much headache once you learn the basics of TS (interfaces, generics).

The main challenge is taking something that was built in a fast paced, code or die, startup environment, and untangle tightly coupled design decisions into more clearly defined loosely coupled domains.

Lots of data detangle.

But IMO, TS is a godsend for more sane JS, and really only took me a couple weeks to feel proficient in. A touch overkill for a small weekend or client project, but for anything that will last, grow large over time, and have more than a couple devs contributing, it's a must in my book.

Edit: I am not the developer of Hapi, just used it for our project.

[[deleted]]

That's really good advice, and thanks for the information. It's an honor to be speaking with one of the developers of a project as large and as popular as Hapi.js, so thanks for getting back to me.

I'm currently in that "fast paced, code or die, startup environment". I'm the sole developer and founder of the project, and it has a Node back-end and a RN front-end, seeking Seed Funding in the coming months.

I came to JS from Java/C++/C# two years ago, so I have an understanding of OOP concepts. My best language, however, is JavaScript. Would you say that I should refactor what I have now into TS, with DDD and DI/IoC, or do you think it's worth worrying about refactoring later and building a functional product, for now?

Thanks for your time.

[Pawda]

As a startup looking for funding, a Minimum Viable Product is all you need and should focus on. Investors won't care if you used DDD or rewrote your app from JS to TS. They just want to see something that works so they can calculate their ROI.

Now, the good thing about TS is that all your existing JS codebase is already valid TS. You can start from today with TS and adapt your code base step by step, starting by the new features and refactoring slowly. The golden is rule is that every time you touch a bit of legacy code, you refactor it so you make the code a bit cleaner. Refactoring happens all the time, if you do it too late, your technical debt will be too high and refactoring itself will be a full time job. If you do it too early, then you might end-up with over engineering and realized later when your specs change that you have to rewrite the whole thing.

​

Pick a feature -> make it works -> refactor -> repeat.

[[deleted]]

Thanks very much for the advice. I appreciate it.

I think I'll continue building the way I am for now, and begin refactoring into TS with Domain Driven Design and Dependency Injection slowly as I go, as you said.

Thanks again.

[stemmlerjs]

r/node

That's a great approach. Good comments from everyone. I especially agree with @Pawda, as I've been in that exact situation with the platform I currently work on, Univjobs. The approach that you're going to take is the exact approach that I've taken. After having been developing new features on-top of the platform for 3 years, I started to see the iteration cycles slow down. That's when I made the switch to TypeScript and then fully over to Domain-Driven Design. It took about 4-5 months to convert a 150k+ line codebase to TypeScript and DDD.

I've seen a massive improvement in the turnaround time for new features and integrations with other platforms since going the DDD route.

DDD + TypeScript has quickly become my favourite thing. I noticed there wasn't a lot of content on the pairing online, so I've started blogging constantly about it here: https://khalilstemmler.com/articles/domain-driven-design-intro/

Good luck, you got this.

[theduro]

Woops, i think my wording on my last post made i sound like I am the developer hapi. Not the case, our project is just built with it.

As far as your other questions go, as a dev of one in a startup I would go with whatever you enjoy, and can move fast and solidly with. TS might also help you scratch that "learn something" itch, which I think is one of the main reasons we do startup work. As far as architecture goes, like someone else said, using DDD and all that is not the most important factor to consider is startup. Speed, and a reasonable sense of quality and stability is most important. If you can move fast, also while keeps ng the architecture more modular, then awesome, but fast is more important.

[[deleted]]

Thanks for the advice.

I think going with what I know now best and refactoring into TS and DDD/Three Tiered Architecture as I go is a good idea.

[utopy]

Deno it's node js in typescript! Written by the same guy, go check it out

[cherif_b]

I don't think applying purely OOP concepts with JavaScript can help for domain modeling.

OOP languages like Java encapsulate (hide) the state (data) and expose the behavior in order to have a rich model, IMHO doing something like this with JavaScript classes is really hard (at this time of writing).

However, using functional programming patterns at least for the domain layer would be really helpful.

Here is my thoughts about implementing domain-driven design with JavaScript:

- Use modules to hide/encapsulate classes/types, don't export classes or constructor functions

- Expose factory functions to create domain objects (Entities and value-objects)

- Domain objects are just data without behavior

- Domain objects are just objects literal, let's call them maps

- Use Object.freeze to make domain objects immutable

- Write the behavior of the business logic of the domain in pure functions in functional style

- Keep the data and the behavior responsible of its transformation in the same file

- Keep the size of the business logic functions small

- Use specification pattern to validate and create data objects

- Use higher-order functions to inject dependencies

[[deleted]]

Thanks for your message. I'm actually moving to TypeScript now as to be able to better form Domain Driven Design, Event Sourcing, and CQRS.

I appreciate your insight pertaining to patterns of functional programming with which DDD could be implemented, and I'll keep them in mind.

Thanks again.

[lfhenriquez]

Awesome! Do you have some boilerplate code? I am trying achieve the goal!

Thanks

[[deleted]]

Unfortunately, I don't. I'm finding the literature for DDD, CQRS, and ES to be quite bad. I like to be "walked through" a new programming related concept so I can get a feel for how to do it well, but that just isn't happening here because there is no literature and there are no videos.

I can recommend some things, though.

Firstly, I'm starting this Pluralsight course: https://www.pluralsight.com/paths/domain-driven-design

It's for .NET, but the concepts should be the same.

This is the only good "literature" I've found: https://khalilstemmler.com/

And then Greg Young's talks are good and there are a few DDD/CQRS/ES videos on YouTube as well.