RFC: Change "use case" to "interactor"

[seppeljordan]

What we currently refer to as a "use case" is actually not a use case but a user action, which can be part of one or more use cases. User actions are facilitated through an Interactor. Up until now, we've been referring to this Interactor as a use case, which we intend to change. A use case is a process that can involve multiple actions from various actors. Use cases are formulated for the specification of the application and generally do not have a one-to-one correspondence in the code.

The incorrect usage of the term "use case" is confusing and leads to misunderstandings, especially among newcomers to the production collective. Therefore, we propose the following steps:

1. Rename all use case classes to Interactor classes. For example: ListAllPlansUseCase -> ListAllPlansInteractor. This explicitly includes the renaming of associated constructs, such as request and response classes or test modules.

2. Create a document (e.g., on ReadTheDocs) that explains the concepts of Interactor and Use Case.

In the future, the term "use case" could be revisited and expanded upon in our documentation.

[sloschert]

I think we called it "use case" because of the clean architecture. When I read the beforementioned blog post of Uncle Bob or e.g. this discussion, I have the impression that we are not too far away from "use cases" as defined in the clean architecture. "Interactor" seems to be a less prominent naming in clean architecture. So are things really getting clearer by this change? Is our current naming really confusing for programmers that are familiar with clean architecture?

[seppeljordan]

Yes, I do think that our usage of the term "use case" is confusing since most people either have a naive understanding of the term, where a use case is "something the user wants to do with the system", e.g. "confirm that a consumption was registered" or "register another worker as part of a company" OR they have a informed understanding based on the literature on the topic. Ivar Jacobson, one of the pioneers of OO design and an explicit reference of Uncle Bob (he recommends his books in many of his talks), defines use case in the following way:

An instance of an actor carries out a number of different operations on the system. When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialog with the system. We call such a special sequence a use case. from "Object-Oriented Software Engineering" by Ivar Jacobson, Revised Fourth Printing, 1992 Addison-Wesley, page 127

Both definitions target the specification of the software and do not talk about program code. In my opinion we should avoid mixing those design concepts with the actual code or technical aspects of the software. Use case should be a term in the specification of the system (which we have to develop in parallel to the programming since we are developing utopian/speculative software) while the term interactor (which is preferred by Uncle Bob, he calls those classes "use case interactors" and not "use cases") is a concept reserved for the code/implementation. A use case interactor can in fact reference a use case from the spec but IMO we should avoid enforcing a one-to-one relationship between the two.

edit: type "use case" -> "use case interactor" in the last sentence.

[sloschert]

Ok, thanks for clarifying!

[4lm]

I discussed this /w seppljordan f2f on Saturday and come to the same conclusion and therefore support this RFC.

[Amittai-Aviram]

Personally, I, too, have always found the current naming scheme confusing, so I support this RFC. I do not expect a use case to be a class, I expect it to be a sequence of actions imagined by the developers in designing the system and then formalizing the design in their specifications. The central idea of a use case is need: what does a user need from the system. When we design the system, we ask ourselves that question, try to think of possible use cases (cases in which the user uses the system, i.e., needs that the system should fulfill), determine what elements are necessary to implement the use case, and formalize those into specifications.