2

In Clean architecture

Suppose I have two actions (approve/deny) a request.

  • Should I create a use case for approve and another for deny?
  • or both in one use case (RespondToRequestUseCase) and I determine the action type through the request model?

knowing that they are sent to back-end by the same API

the difference between them is that the user should enter a reason in case of deny.

Mohammad Alotol
  • 147
  • 4

2 Answers2

3

Well, how do your two actions fit within the business processes you're modeling?

Clean Architecture doesn't tell you how to define use cases. This is up to you and your conceptual understanding of the domain. Nobody who's not involved with the project you're on can tell you what to do here - besides providing generalized advice. This is for you to determine/design.

Basically, to figure this out, ask yourself (or other stakeholders) if the similarity is only superficial (the superficial mechanics are the same, but on a deeper level the use cases have aspects that you deem sufficiently different), or if the core logic and the role they play within the context of the domain is largely the same for both, meaning there's a way to come up with a unified representation of these use cases in your code/architecture. A proxy for that could be to find out whether or not the business already treats, in their existing procedures/workflows, these use cases as separate. Another thing to consider is if the similarity is expected to be temporary - are these use cases expected to evolve into different directions as you develop the software? If you aren't sure how to answer these questions, you can ask your customers / users / domain experts for more info.

Note that, if your requirements are vague, or represent only an initial pass of the spec, you may start off one way based on what you initially know, then figure out later on, as you learn more, that you should merge or split them. That's fine. On the other hand, if, early in the process, you have a deep understanding of the what-s and the why-s that are behind your requirements, you might be able to come up with use cases (or some other form of conceptual/architectural decomposition) that you won't have to reshuffle later.

What I'm trying to say is, as posed, the question doesn't really make sense. The question of which specific use cases you have is not something prescribed by Clean Architecture (which is a generalized idea) - this is the analysis part, the "some design up front"1 part of Agile. This is you (and/or your team) trying to figure what it is that your customer actually needs you to build for them and why, and trying to capture this understanding as a set of use cases that align with their business needs (but that, ultimately, you made up based on what you understood).

If you're experiencing "analysis paralysis", then just pick one or the other, and then keep track of how it's working out. If you run into design problems later, you'll probably be in a better position to correct them and incrementally redesign - if you don't wait too long and try to shoehorn things that fit less and less for the sake of "consistency".

1 Agile recommend against "big design up front", but some people wrongly interpret that to mean "no design up front at all". There has to be some amount of analysis/design, it's just that it should happen in smaller chunks, with faster feedback, and iteratively (dropping off over time as you hone in on the right architecture).

Filip Milovanović
  • 8,428
  • 1
  • 13
  • 20
0

We could probably re-phrase the question as -

should there be a use case per Repository method?

This is a very common question and the answer is: most probably yes. Clean Architecture is a Use Case driven architecture, hence each repository method exists only because it is supporting a Use Case.

class UseCase
{
    private Presenter presenter;
    private Repository repository;

    public UseCase(Repository repository, Presenter presenter)
    {
        this.presenter = presenter;
        this.repository = repository;
    }

    public void Execute(Request request)
    {
        ...
        Response response = new Response() {...}
        this.presenter.Show(response);
    }
}

Note: Use Case can use more than one Repository though.

Do read: Clean Architecture: Use case containing the presenter or returning data?

A G
  • 243
  • 1
  • 6
  • Thank you Aseem, – Mohammad Alotol May 10 '22 at 10:54
  • 1
    I know that, but we can create a single use case and add condition in it -which is the higher level of abstraction- to choose between gateway methods(approve, reject), so we use a single use case with a single controller. - another way is to make different use cases with different controllers and each use case directly handles a gateway method without checking the type of the action passed through the request model. – Mohammad Alotol May 10 '22 at 11:01
  • 2
    Conditions usually violate SRP. You should almost never want to have an if-else construct inside a use case. Controller can make use of as many use case(s), there is no constraint that one controller should call only one use case. – A G May 10 '22 at 11:08