CODEWITHSUNDEEP
architectureclean-architectureuse-case
Jop Middelkamp
Jop Middelkamp

Reputation: 153

Always use use cases or not?

I've been wondering a little about use cases in my latest project. It seems like there are many use cases with only one line of code just forwarding the message to a repository.

Now as I understand the use cases should contain business logic only just forwarding a message has nothing to do with business logic most of the time. It feels like creating a use case for every action is a bit overkill. And I'm starting to lean towards direct communication to a repository unless the use case would add value like for example the RegisterUserUseCase which does multiple calls to different repositories.

How do you guys feel about this? Which approach do you follow? And why do you do so?

Kind regards,

Upvotes: 1

Views: 680

Answers (1)

René Link
René Link

Reputation: 51463

The task of a use case is to:

  • validate the request model (in meaning of business rules)
  • query or persist entities with repositories
  • implement the application specific domain logic.

A use case is also often the transaction boundary or other aspects are handled at the use case level.

There are some use cases that do not a lot of business logic or even none, like a data export use case. Those use cases should be rare, but even those use cases usually validate the request model. I would prefer to keep the architecture even in those rare use cases to be consistent.

If you have a lot of use cases that do not contain any business logic, your business logic is probably spread accross the controller and/or repository or application specific logic moved to the entities which should only contain application agnostic business logic.

Upvotes: 1

Related Questions