Understanding Different Use Case Invocation Patterns

[adrianofoschi]

Summary

I'm studying this template to understand the architectural patterns and noticed different approaches for invoking Use Cases between the Auth and User modules. Could you help explain the reasoning behind these design choices?

Observed Patterns

Auth Module Pattern

  // AuthController calls UseCase directly
  @Post('/login')
  async login(@Body() body: LoginBody): Promise<JwtUser> {
    return this.jwtAuth.generateJwtUser(
      getOrThrowWith(
        await this.loginUseCase.execute(body), // ← Direct UseCase call
        () => new UnauthorizedException('Login Error!'),
      ),
    );
  }

User Module Pattern

  // UserController uses CQRS Command → Handler → UseCase
  @Post()
  async createUser(@Body() body: CreateUserBody) {
    getOrThrowWith(
      await this.commandBus.execute(
        this.getCommandForRole(body, UserRole.USER), // ← CQRS Command
      ),
      () => new BadRequestException('Error in User Creation'),
    );
  }

  // Then CreateUserHandler calls the UseCase
  @CommandHandler(CreateUserCommand)
  export class CreateUserHandler implements ICommandHandler<CreateUserCommand> {
    async execute(command: CreateUserCommand): Promise<Option<User>> {
      return await this.createUserUseCase.execute({
        // command properties...
      });
    }
  }

Questions

1. What are the design principles behind choosing Controller → UseCase → Command vs Controller → Command → UseCase?
2. Are there specific scenarios or requirements where one pattern is preferred over the other?
3. For the cross-module communication (Auth's SignupUseCase dispatching RegisterUserCommand handled in User module), isn't this an obstacle to moving to a microservice architecture with minimal effort?

Thank you for creating such a comprehensive template with excellent DevOps practices!

[andrea-acampora]

In general, there's no a perfect or standard way to apply these principles and it really depends on the domain and on the developer preferences.
The template intentionally shows both styles to illustrate that your application layer can use CQRS as strictly or as flexibly as your context requires.
Anyway let's try to look at the two approaches:
Controller → UseCase → Command vs Controller → Command → UseCase

• Controller → UseCase → Command
  I'd use this approach when the use case is big enough to coordinate multiple smaller commands or operations.
  In this way, inside the use case we might still dispatch CQRS commands if sub-steps need to be handled asynchronously or by other bounded contexts.

• Controller → Command → UseCase
  On the other hand, this version embraces the full CQRS flow and is ideal when each controller endpoint maps cleanly to a single command that encapsulates intent.
  It provides a consistent “message-based” entry point into the domain layer (commands express what should happen, handlers express how it happens and use cases implement the application logic behind it).

Related to the third question, you're actually right and in a microservice architecture having an Auth use case directly dispatch a RegisterUserCommand to the User module could create tight coupling if both were separate services.

However, in this modular monolith-first setup, it’s intentional and It allows us to:

• keep cross-module communication explicit via the CommandBus (so later it can be replaced by a message broker).
• avoid premature microservice boundaries while still enforcing modular isolation through interfaces and commands.

Given this, when you move to a distributed system, you only need to replace the in-memory CommandBus with an external transport (e.g. Kafka, Rabbit or any other Nest microservice transport).
The contracts (commands, handlers, events) could remain the same and that’s exactly what makes this DDD + CQRS approach so good (at least to me).

@adrianofoschi