design-patternsarchitecturedomain-driven-designclean-architectureuse-case

Use cases vs Domain vs Repositories: Where should the business logic reside?


Upon using Clean Architecture for multiple Android projects, I always stumbling with a temptation on where is the best location to put the business logic. Based on my understanding Domain Model holds some business logic and value objects that solves problems like formatting or encoding, Use Cases on the other hand provides the "Screaming Architecture" concept to make actions and processes more readable in a business perspective but in abstract. There is also Repositories that are responsible for transmitting/receiving or storing data but can also have business logic in it.

My questions are:

  1. Is it possible for Use Cases to have business logic as well? If yes what kind of business logic it can have?
  2. What kind of business logic Repositories usually have aside from transmitting/receiving or storing of DTOs?

Solution

  • Is it possible for Use Cases to have business logic as well?

    Yes, said Robert Martin in 2012.

    what kind of business logic it can have?

    "The software in this layer contains application specific business rules." Note that application specific is distinct from "enterprise wide".

    What kind of business logic Repositories

    I would not expect business logic in repositories.

    "your business rules simply don’t know anything at all about the outside world."

    Would be a strange statement to make if including business logic in repository implementations was a normal/common/desirable pattern. Repositories are, for the most part, plumbing that we use to move information around.