Well, I've been studying software architecture a lot, Clean Architecture in specific and I came across some multi meanings terms and "Use Case" is one of them.

I'd read in some places that we don't have a defined connection with use cases from CA and use cases from requirements specifications in software engineering nor use cases from Use Cases Diagrams in UML.

Even though, I saw a lot of articles and tutorials using these different usages in only one place: using some Use Case Diagrams and documentation techniques to describe some interactor/use-case class in a project using Clean Architecture.

So I wanted to know if there's something concrete about differences and similarities between these three usages/meanings.


1 Answer 1


In short

In the general sense, use-cases are meant to focus on user objectives and answer the question: "why would a user use this system? And for what purpose?". They therefore focus on user objectives and business needs. Clean architecture used this term to refer to elementary business transactions and business logic.

Traditional use-cases tend to be of high level. Clean architecture use-cases tend to be at a much more detailed level. UML allows to cover the full spectrum, although many authors recommend to stay at the level of the big picture.

Some more arguments

Use cases in the the general meaning

The use-case originated in the area of requirement engineering to identify user goals and focus the analysis on the user perspective.

Ivar Jacobson, the inventor of use-cases in the early days of OOP defines them in his more recent Use Case 2.0:

A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.

Alistair Cockburn, used a very similar definition in his book Writing Effective Use-cases:

A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system's behavior under various conditions as the system responds to a request from one of the stakeholders called primary actor. The primary actor initiates an interaction with the system to accomplish a goal.

UML has defined use-cases in a more neutral way, in order to allow its use for requirements as well as functional design:

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...) it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. (...) UseCases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. [i.e. subjet = system]

The use-cases tend for these reasons to focus at the business view. The very neutral UML specifications even clarifies that:

UseCases define the offered Behaviors of the subject without reference to its internal structure.

Use cases in clean architecture

R.C. Martin took over the general term of use-case with a slightly different meaning, although there is some relevant overlap:

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

What he means there is in fact elementary business transactions that are defined only in terms of use of entities and business logic. An hence the overlap with the traditional term, since it results from a use-case analysis as explained here:

After an informative briefing from the stakeholder, he performs a use-case analysis, and a high level object-oriented design to create the architectural superstructure on which the rest of the application will be built

The consequence is that Clean architecture use-cases tend to be more granular than traditional use-cases. They correspond to elementary business functionality at "function" or "sub-function" level (e.g. "find a customer", "find an order", "invoice order") whereas the goal-oriented use-case analysis tends to describe higher level user objectives ("Invoicing customers"). But it's mainly a matter of level of details.

Personal remark: What is annoying with R.C. Martin's appropriation of the term, is that "use-case" is more an more used to describe some system functionality ("I have my API for use-case X") instead of encouraging a focus on the user's needs as initially intended.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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