36

I'm going into Clean Architecture and lift my Android level from MVC to MVP, introducing DI with Dagger 2, Reactivity with RxJava 2, and of course Java 8.

In MVP clean architecture there is a layer between the entities (in datastores) and the presenters that should access them. This layer is the "Use Case". An use case it's ideally an interface, that implements ONE operation on ONE entity.

I also know that Clear Architecture "is screaming", in sense of its projects are really highly readable as the high number of classes in them.

Now, in my project, I have something like 6 different entities, and of course, each entity repository has at least 4 methods (usually get,add,delete,update) to access them.. so, 6 * 4 = 24.

If what I understood until now of Clean Architecture, I will have 24 UseCase.

This is a lot of classes if compared to just 6 controllers in MVC..

Do I really have to make 24 use cases?

I will really appreciate a clarification by someone already used it with success.

Improve this question
7

4 Answers 4

Reset to default
43

Do I really have to make 24 use cases?

Only if everything you write is CRUD.

Refer to the diagram below:

enter image description here

Your assertion is that you will have six different entities, and 4 methods (Create, Read, Update and Delete) for each entity. But that is only true in the yellow circle in the middle of the diagram (the Entities layer). It is pointless to create 24 methods in the Use Cases layer that merely pass through CRUD calls to the Entities layer.

A Use Case is not "Add a Customer Record." A Use Case is more along the lines of "Sell an item to a customer" (which involves Customer, Product, and Inventory entities) or "Print an invoice" (which involves the same entities, in addition to Invoice Header and Invoice Line Items).

When you create Use Cases, you should be thinking about business transactions, not CRUD methods.

Further Reading
Aggregate - a cluster of domain objects that can be treated as a single unit

Improve this answer
16
  • 6
    You're spending too much time thinking about patterns, practices and architecture, and not enough time thinking about basic software design. All you need are methods that embody business practices, as I described in my answer.
    – Robert Harvey
    Commented Dec 10, 2017 at 17:21
  • 2
    It's not a question of choosing an architecture. My personal opinion: bare CRUD operations should talk directly to the Entity Layer. Of course, this probably violates Clean Architecture.
    – Robert Harvey
    Commented Dec 10, 2017 at 23:06
  • 3
    You're kinda missing the point. Architecture is just a means to organize code. You solve problems by writing code, not wrestling with architectures.
    – Robert Harvey
    Commented Dec 11, 2017 at 16:18
  • 4
    Hey Robert, it's not so nice that you assume that I dont write code. The topic of my answer it's on architecture, and we're not on SO. Sincerely I find your last comments really misleading and deaf. The question is about UseCase in Clean Arch., not writing code. If you're trying to communicate something please explain better, because I'm missing the point of your comments. IMHO it's not possible to avoid Architecture consideration while developing software, or at least, good devs doesn't just write bunch of code. Moreover I asked a really specific question in my comment, can you answer? Thanks
    – Jackie Degl'Innocenti
    Commented Dec 11, 2017 at 17:32
  • 2
    The solution to the problem you posed (app offline first) doesn't really have much to do with Clean Architecture. You won't find a solution to that problem in the Clean Architecture diagram.
    – Robert Harvey
    Commented Dec 11, 2017 at 17:34
4

You are right if every CRUD-Operation is translated in one UseCase. But a UseCase may also consist of multiple CRUD-Operations.

A UseCase is a separated model gathers information from different data sources and prepares communication to data sinks. There can be multiple CRUD-Operations be involved.

So think of a UseCase where creating an invoice for a customer AND creating also the customer itself because he/she doesn't exists within the system. You have one UseCase that results in at least two Create-Operations in one transaction.

Improve this answer
5
  • So what pattern would you reccomend for the example of the CRUD with many entities?
    – Jackie Degl'Innocenti
    Commented Dec 10, 2017 at 9:32
  • My personal view on this is: I have no problem to have many classes as long as they do not violate SRP (single responsibility principle). But I most of the time would redefine the Usecases "create an entity", "update an entity", "delete an entity" and "update an entity" to a simple "manage entity of type X". Often you provide a single UI to manage one entity. But that is exactly what your UseCase should define: The way to handle a beneficial load of work for your business.
    – oopexpert
    Commented Dec 10, 2017 at 14:20
  • Ok, so, having a Use Case that manages various different operations doesn't seem to violate SRP as it seems to just "aggregate" more different methods (and flows) in the same UseCase without that any single flow handle more than one responability... but in this way aren't we just creating a controller in place of an UseCase? .. idea .. Maybe the Use Case must be simply seen as a layer, and that layer just have to respect SRP but can also implements many methods. I would like to have a source or article about this
    – Jackie Degl'Innocenti
    Commented Dec 10, 2017 at 21:30
  • 1
    A Usecase IS A controller. The only difference is, that a usecase comes from the business perspective and a controller is the technical view on it. The focus of a usecase is, what is generating the business value. So a usecase is a business value driven controller implementation.
    – oopexpert
    Commented Dec 11, 2017 at 0:32
  • 1
    Agree, an HTTP controller is a way of managing I/O, there can also be console commands, event reactions and so on. All these I/O channels call the same usecase. A usecase IS a controller for business logic, it does not know about the I/O channels it was called from, but it knows how to orchestrate domain entities to do the job.
    – Dmitry Lezhnev
    Commented May 20, 2019 at 7:11
3

It's assumed that clean architecture is used in business heavy applications, where use cases are mapped to business rules. In a CRUD app it's over-engineering. Here you can use facade and map requests directly to the db entity. When logic grows, refactor and extract use cases, validators, domain objects etc..

Improve this answer
1

Your definition of Use Case is wrong, Use Case is a class implementing a business rule, it does not need to be a CRUD operation, it can be a complex multi step operation

Improve this answer
1
  • 1
    Your sentence doesn't mean a solution when you actually need to implement a wide range Crud-like operations, even your consideration may found some relation to the fact that an Use Case should observe a pattern in which we could access to a complex operation, even multi step.
    – Jackie Degl'Innocenti
    Commented Mar 14, 2019 at 13:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.