clean architecture nestjs

[ruby dock]

i used this article for develop
https://github.com/jonathanPretre/clean-architecture-nestjs

when i try to use rabbitmq(@messagepattern) for listen automatic
but when in @module set usecase proxy and rabbitmq , this app dont allo for listen
I tried both methods below, but it didn't work

@Module({
imports: [
ClientsModule.register([{
name: 'GREETING_SERVICE',
transport: Transport.RMQ,
options: {
urls: ['amqp://localhost:5672'],
queue: 'hello',
queueOptions: {
durable: false
}
}
}]),
UsecasesProxyModule.register()
],
})
export class AppModule {}

OR

@Module({
providers: [],
imports: [UsecasesProxyModule.register()],
controllers: [RabbitmqController, AppController],
})
export class ControllersModule {
configure(consumer: MiddlewareConsumer): any {
consumer.apply(AuthMiddleware) .forRoutes('*');
}
}

[neat nacelle]

Please format your question or answer with Markdown formatting.
It leads to better readability and an easier time to spot problems.
For code blocks, you can wrap your block with three back ticks before and after the block, and after the first three back ticks you can add a language (like ts) to add syntax highlighting.
e.g.

```ts
@Injectable()
export class MySuperAwesomeService {
constructor(@Inject('InjectionToken') private readonly dep: SomeDependency) {}

getRandomNumber(): number {
return Math.round(Math.random() * 1000);
}
}
```

Becomes :point_down:

@Injectable()
export class MySuperAwesomeService {
  constructor(@Inject('InjectionToken') private readonly dep: SomeDependency) {}

  getRandomNumber(): number {
    return Math.round(Math.random() * 1000);
  }
}

[errant temple]

Also, I'd also highly suggest not using that method of structuring Nest code. It will be a nightmare, when your code base gets bigger.

[ruby dock]

Thank you for your opinion
Why do you think this design is bad?

[errant temple]

Because it breaks up Nest's modular approach to "fit" things into different chunks of application architecture, instead of having modules represent features. Have a look at my article. It will explain the better and "best practice" way to use Nest. https://dev.to/smolinari/nestjs-and-project-structure-what-to-do-1223

[ruby dock]

Thank you

[errant temple]

Hihihi.... https://github.com/jonathanPretre/clean-architecture-nestjs/issues/4

The fact the author doesn't even reply should tell you alot about his approach and how much he believes in it.

[ruby dock]

I have used this architecture
In your opinion, if I replace usecaseproxy with direct export, the problem will be solved?

[errant temple]

I have no idea. What error are you getting?

[ruby dock]

i cant use ClientsModule.register by UsecasesProxyModule.register() in appmodule
and i cant use RabbitmqController by UsecasesProxyModule.register() in ControllersModule

[errant temple]

That doesn't explain the error you are getting. When you run start:dev, what do you see?

[ruby dock]

i dont have error only @messagepattern dont work

[errant temple]

And how does it "not work"? What do you see?

Or not see?

Can you offer a minimum reproduction repo?

With steps to reach the point of the error/ problem?

Also, why do you need RabbitMQ? What purpose are you using it for?

[ruby dock]

I have written a microservice to save the logs
I want to use it to communicate with the main microservice

I will ask permission from the manager to send you a copy

I thank you for your help and guidance

[errant temple]

@ruby dock - Ok. I've also added an additional note to my article about why structuring your Nest application around DDD is a bad idea. Here is the text:

Additional Note 2: One of the things I see people often attempt, is to try and fit "DDD" into the file structure of a Nest project. Nest is flexible enough to allow for this, however you end up with two problems.

1. Actually fixing a problem requires sifting through those different layers of the file system you've determined to be "proper" for fitting your app to "DDD". Whereas, if you just keep the DDD within each module, as Nest prescribes, you just need to go to that one module to fix the problem.

2. The bigger issue, you've broken up Nest's module system and thus the ability to reuse code/ modules as libraries. Maybe not a big deal for those just starting, but it will be when you realize you could take a lot of code and reuse it in new or other Nest projects.

To me, and this is my personal opinion, DDD should be a guide to how you think about your application, not necessarily how you design your file system/ project structure. When you come across a problem in the real world, either it being to enhance or to fix the application, nobody should need to rethink about the locality of code according to DDD to fix it. That is just going to waste a ton of time. Use Nest's "way of modularization". That is the standard you should work with. Keep DDD in your mind, when dealing with the overall problem and keep it away from the code structure. It just isn't necessary.

[ruby dock]

thank alot

[lost gate]

If you really want to maintain the DDD layer names, then do that within a module. Like, don't set up a top-level layer folders, but do that within each module like if it were an HMVC pattern. That way you can keep the naming scheme and mental model clear, and also utilise the module system that Nest provides 🙂

[analog warren]

DDD doesnt have specific layers 🤔

[lost gate]

Fair, though people tend to introduce things like framework, connectors/providers, infrastructure, and domains for some reason.

oh and the always creeping utils

[analog warren]

I mean a big chunk thinks about tactical design when they hear DDD and link it with architectures like hexagonal and clean arch but nobody ever said that these two are the same / have to be used together. Strategic design is where it starts. How you eventually implement it doesn't really matter.

[lost gate]

I am not so sure that implementation would not matter, especially when you working with a framework that already has its own design and expectations you should incorporate into your overall architecture. Sure, you can force any design onto anything, but that usually fails once you try to scale it up to either more developers or more load.

[errant temple]

Yeah, it shouldn't. But it is often sold as having some. Like this:

[lost gate]

I like the "Real-Life Application" 😄

so far I haven't seen any of these reference and prove that reference of a real-life application

[errant temple]

I probably brought in the DDD here because I mentioned it. The OP was speaking about clean architecture. So, my bad.

I just wrote this in a reply to an article:
To me, DDD is about how you break down the business problems and should be less about the software architecture. You can "think" in DDD, but work in clean architecture. DDD would, at best, help you to design how you build the use-cases and entities (aka services in SOA). So, they aren't mutually exclusive at all.

The question being, is DDD and Clean / Onion Architecture mutually exclusive.

[lost gate]

I don't think so, like DDD to me is more of a practice to isolate similar topics and establish a well defined group with its language, while onion ism ore about what layers you may need within those groups. Though quite often people establish the layers and duplicate the groups in each layer, which I am against.

[analog warren]

DDD is both. It's whole concept is around defining an ubiquitous language so that both the stakeholders and developers understand each other, this also includes figuring out the business use cases. Just like we are noticing now context also matters, "group" could mean different things for different people. That's all strategic design though. The tactical design of DDD gives us tools to translate those domain concepts but how you eventually structure your application is not defined in DDD but many have considered archs like hexagonal, clean, onion to be a solid pick because they are all focused on layers of indirection. Atleast, that's how I see it.