35

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.

Rohit Gupta
  • 203
  • 2
  • 3
  • 12
Jackie Degl'Innocenti
  • 485
  • 1
  • 4
  • 9
  • 1
    Can you post a link to a page that describes these Use Cases in detail, with example code? – Robert Harvey Dec 08 '17 at 22:55
  • I have googled a lot, but mainly: this app sample and related article: https://github.com/jshvarts/OfflineSampleApp ; this articles: https://proandroiddev.com/build-an-app-with-offline-support-exposing-network-states-1e09e138b1ed ; https://proandroiddev.com/build-an-app-with-offline-support-exposing-network-states-1e09e138b1ed ; This Talk: https://www.youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; And this articles too: https://adityaladwa.wordpress.com/2016/10/25/offline-first-reactive-android-apps-repository-pattern-mvp-dagger-2-rxjava-contentprovider/ – Jackie Degl'Innocenti Dec 08 '17 at 23:09
  • 1
    None of the sample apps or articles you cited appear to have much to do with Clean Architecture. They do, however, talk a lot about *reactive programming.* – Robert Harvey Dec 08 '17 at 23:27
  • The sample app is surely made with Clean Architecture paradigm.. The other articles mostly.. What do you want to see @RobertHarvey? – Jackie Degl'Innocenti Dec 09 '17 at 11:04
  • Read my answer below and reply. – Robert Harvey Dec 09 '17 at 16:40
  • I'm currently where you were at 3 years ago when you asked this. I get the feeling from [this article](https://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576) that it is fine to have use cases that merely call a repository method. "A Use Case per Repository method? This is a very common question and the answer is: most probably yes." And he lists some benefits of these "useless use cases". He doesn't think the ViewModel should deal with repositories at all, they should only deal with use cases. In that case, use cases must be used for simple CRUD tasks. – BeniaminoBaggins Nov 17 '20 at 04:51
  • Thank you for pointing out, I just want to specify that in the end I used a pattern wherein I've aggregated some methods (not much, usually just a couple, i.e. for lists: for the first data retrieval and for sync) in the same view model linked to a specific view. This reduced a bit the number of viewmodels and helped in mantaining a clean binding from views to data repositories (api and db). Feel free to make questions on other technical aspects I'll be glad to give you my best knowledge indeep. Cheers. – Jackie Degl'Innocenti Nov 18 '20 at 12:53

4 Answers4

42

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

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Well, I understand that the UseCases could aggregate multiple operation in its execution, by the way, as of the example, if I would have to create a CRUD for 6 entities, I will still have a lot of classes. At this point, I think this is what the clean architecture impose. Anyway, it is a good practice to try to "aggregate" multiple entities operations involved to make the UseCase cover a complete action, as a transaction, and not a single part of the operation. This is like moving some of controller logic inside the use case, but with "Single responsibility principle". – Jackie Degl'Innocenti Dec 10 '17 at 09:26
  • When you say "It is pointless to create 24 methods...", so would you recommend another design pattern for this goal? Like MVC? It's possible to have a project with half Clean Arch. and half MVC? – Jackie Degl'Innocenti Dec 10 '17 at 09:30
  • 5
    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 Dec 10 '17 at 17:21
  • Robert, I would like to embrace your suggestion but it's not enough pratically clear what to do because not all the projects just consists in complex operations, often it just is a simple crud operation. Are you suggesting to drop clean arch in favor of MVC if it mainly consist in crud ops? Or, what do you think of wrapping multiple ops in a ManageEntityUseCase as @oopexpert wrote? – Jackie Degl'Innocenti Dec 10 '17 at 19:27
  • 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 Dec 10 '17 at 23:06
  • Ok, and if (let's put some pepper) every operation has to be an app offline first operation (so working on local DB _and_ with network API), would you still skip the UseCases Layer or, in this case, use it with the screaming it follows? – Jackie Degl'Innocenti Dec 11 '17 at 11:23
  • 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 Dec 11 '17 at 16:18
  • 3
    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 Dec 11 '17 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 Dec 11 '17 at 17:34
  • 1
    Well, if you had read the article and sample project source I wrote on the comment of my answer, you would know what we are talking about. – Jackie Degl'Innocenti Dec 11 '17 at 17:37
  • Which one? You linked to a lot of them, mostly discussing reactive programming. I think we can get our discussion a bit more focused than that. Perhaps you can quote some of the article you are referring to? – Robert Harvey Dec 11 '17 at 17:37
  • 1
    I tell you what. Why don't you post a new question about your "app online first" issue, and I'll respond to that directly. Make sure you include in your new question all of the information that the community needs to respond adequately, including any information you found in blog articles, etc., that you believe is relevant to your question. – Robert Harvey Dec 11 '17 at 17:40
  • @RobertHarvey So basically you create entity method if the method is changing self state, and you create use cases if multiple entities are involved or some external resources (DB, etc...)? –  Nov 06 '18 at 09:49
  • Just for giving a closure on this: I ended up organizing the code by using multiple methods inside a single UseCase, so i.e. of the question, I would have just 6 Use Case with 4 methods each. – Jackie Degl'Innocenti Feb 16 '19 at 15:22
  • In terms of android development, can is it a good practice to just write the business logic in the ViewModel class or do I need to create a separate class for the use case as shown in the diagram. I feel like the ViewModel belongs to the green circle. – Lance Jul 01 '21 at 18:22
  • @Lance: You haven't mentioned anything about your specific application or its unique requirements. Like all software development questions, the one you describe is best answered within the context of your specific application. – Robert Harvey Jul 01 '21 at 19:30
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.

oopexpert
  • 769
  • 4
  • 7
  • So what pattern would you reccomend for the example of the CRUD with many entities? – Jackie Degl'Innocenti Dec 10 '17 at 09: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 Dec 10 '17 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 Dec 10 '17 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 Dec 11 '17 at 00: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. – Dmitriy Lezhnev May 20 '19 at 07: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..

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
photostok
  • 63
  • 3
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

Buckstabue
  • 11
  • 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 Mar 14 '19 at 13:08