How to deal with reusable use case?

Question

I'm trying to implement the clean architecture and I'm not sure to quite understand when to reuse interactors (use cases).

Considering that we have one use case such as get user information and we would like to reuse it in different location.

Screen A: product owners decided to display very few user information (pictures and name).

Screen B: product owners decided to display a lot more user information.

Shall we implement two separated use cases (interactors) or a single one?

What about if product owners decide that for Screen B we should not display user information if we don't have all the data retrieved from the API? It will definitely impact Screen A and it won't be valid/SOLID anymore.

Answer 1

In my view a "use case" refers to a user, using the product. Not an internal implementation detail such as an internal API.

so you, presumably, have two use cases

1. as a X I need to see partial data

2. as a Y I need to see full data

Your 2 screens fulfill these requirements, one for each. How they work behind the scenes is up to you

Example "Use Case"

As a "System Admin" I need to view the full details of all "Customers" so that I can do fraud investigations.

Example "User Story" (Scrum terminology)

As a "System Admin" I need to view the full details of all "Customers" so that I can do fraud investigations.

and

As a "Customer" I need to see my name and address, so i can be sure they are correct.

BUT! importantly this is also a to do list item that you are going to pick up and implement, although it may be divided into smaller tasks.

Normally it would be one to one. But I might have multiple user stories per use case.

Example Screen. (Interactor is not a common term)

Web page with a big table of user details.

This might be the result of implementing the user story

Example service class that the screen uses

public class UserRepo
{
    public List<User> GetAllUsers();
    public List<UserLite> GetUsersWithMinimalDetails();
}

Now I can do the sysadmin screen with 'GetAllUsers' and the CustomerDetails screen with GetUsersWithMinimalDetails. Or I could use GetAllUsers for both.

I could have two screens, or one, or three. The use use and the user story dont tell me

Answer 2

You cannot really decide about code reusage when only looking at use case descriptions or user stories: this is typically the wrong level of abstraction. At the highest level, your description says

"get user information"

which gives the impression this is just two times the same use case. Going more into the details, you see there are differences in Screen A and B, which shows these are two similar use cases, but not exactly the same.

If you switch to the code level, it is often possible to find parts which can be reused, others which cannot. For some, it is probably not immediately clear if the reusage will create some unwanted coupling between screen A and B which might affect future changes.

This is a judgement call. Creating reusable components for certain uses cases is not easy. The idea should be to create components following the OCP. So they don't have to be touched in case requirements of one use cases change, and the coupling won't affect other uses cases.