Separation of Students and Users in NestJS Microservice architecture

Question

I need help with the architecture pattern I should use in a NestJS project.

So I am using a command/query approach for developing my RestAPIs. Right now it's a Monolith and not a microservice architecture, but I am developing it in a way that tomorrow it will be easy to switch to Microservice.

So consider a scenario, where I have 2 APIs one is createStudent and the other is createUser. In my application, I have 2 separate folders under src users and students where users will handle all stuff related to users and students will cater to student fees, attendance etc. Each of them has its own entities and repository files.

Also, creating a student involves a step of creating a user as well. So basically let's say for a student to create, a user will be created, its contacts and address details will be saved, instutres detailees will be saved, document details will be saved etc.

Considering this, creating users, contacts, and addresses are part of the user folder, and repository files and entity files related to these are stored in the user folder.

Create student, assign institute to the student, insert documents, are part of the student folder and repository, and entity files related to these are stored in the student folder.

Right now what I am doing is, in createStudent handler, I have injected repositories for user, userAddresses and userContacts and using them in the handler to get/create/update records related to user, address or contacts.

Though I have a separate handler for createUser as well, where I also need to do the same eventually, it will have nothing to do with the student.

I am still able to do stuff I need to do, I am just thinking, that tomorrow If I switch to a microservices approach where the user and student will be different microservices with different databases, I will not be able to inject the repository and somehow need to call the Rest API for user or student to achieve this.

Am I doing it the right way or Is there a way where I can call one handler from another handler in NestJS so that I can segregate the logic in their specific handlers?

The second thought is, if users and students are so closely linked to each other and the exchange of data is happening, should those be segregated into different microservices or not?

Answer 1

So first of all what we're talking about here is not strictly the CQRS pattern, but designing of the domains. Where does the "user" end, and where does the "student" (who's also a "user") start. Encapsulation of logic, stuff like that. Domain-driven development says "hello" :)

First things first.

Right now what I am doing is, in createStudent handler, I have injected repositories for user, userAddresses and userContacts and using them in the handler to get/create/update records related to user, address or contacts.

I'm pretty sure this can be handled with one repository only. If you define relations for user (1:M addresses), any mutation of the data layer can be done with cascade updates:

let user = await this.userRepo.getOne(userId);
const newAddress = new Address({...});
user.addresses.push(newAddress);
await this.userRepo.save(user);

(of course, that's in pseudocode).

I'd think of a general rule to keep one repository, always, per CQRS handler. If something cannot be done with one repository, then it means the scope of that handler is too vast (leaking boundaries, something that's of user's shouldn't be doing direct mutations on address, which is a separate domain).

---

If I switch to a microservices approach where the user and student will be different microservices with different databases, I will not be able to inject the repository

Why different databases, by default? You can have your microservices interacting with your one and only data layer, and that's still valid, unless there are certain reasons for separating databases. You can have your microservices doing their stuff and not interacting with data layer at all, but receiving everything over messaging bus, and over messaging bus responding to the main app that's responsible for data handling. But still, if you inject repository for one entity or schema (if you're using eg. mongoose), and define your relations well, you can still inject a single repository (recommended, definitely) to a microservice, and cascading will work.

But if you will say sth like "but I need to have more than one repository", then it means that domain boundaries should be most likely reconsidered :)