Why not use minimal APIs instead?

[nilaxann65]

When working with DDD, most of the logic resides in the commands/entities, while controllers primarily handle repetitive tasks such as mapping DTOs to commands and managing command responses. However, this could also be addressed using a generic function.

This doesn't mean that I'm suggesting we should use only one controller for the entire module, but rather, we should use criteria to segment the minimal APIs based on the use cases :)

So... why not opt for minimal APIs instead?

[Sairyss]

Nobody's preventing you to use minimal APIs, if it makes sense for your app. For small apps it's usually fine.
In bigger enterprise apps, having a separation between controllers/services/entities makes it more scalable, because it makes code isolated, reusable and resilient to change.

• In bigger enterprise apps, changes to business logic as the app evolves are very common. What was 3 lines of code can become 10, then 15, and so on. Having it in it's own entity/service is better than bloating a controller.
• As app grows, It's easier to maintain multiple files where each file has it's own 'function' (single responsibility), rather than a controller that does everything.
• Code can be reused. Logic in one service/entity can be called from multiple places, even multiple controllers.
• You can generate boilerplate code automatically to make things easier

If you work in a typical startup building mostly CRUD, and If you are facing an issue where you think it would be better to do most things in just a controller, architecture in this repo is probably not the best choice. You can try using something simpler.