Summary: “Use Case” in UML Describes business objectives and user value – a requirements artifact. In Clean Architecture, a UseCase (Interactor) refers to an application operation of the Application Layer that orchestrates repositories/services. These are different abstractions with different purposes. Clearly separating the two avoids misunderstandings and architectural erosion.
A brief misunderstanding to start
PM: “We need two new use cases: Login and Save note.”
Developer: “Okay, I’ll create two use cases and bind them to the repositories.”
Architect: “Hold on – one is UML use cases, the other is application use cases. Let’s be precise, otherwise we’ll be talking past each other.”
What a UML Use Case Actually Is
In UML, when we talk about a use case, we mean a business intent from the user’s perspective: a goal, a value proposition, formulated independently of technical implementation. A use case typically includes stakeholders, a primary scenario, and alternative flows (e.g., offline, lack of permissions). Its purpose is stakeholder alignment, scope definition, and acceptance criteria—not the definition of classes, repositories, or databases. The UML use case is therefore a requirements artifact, not a code artifact.
The following PlantUML sketch shows a simple example of a note-taking app. It makes visible what the system is supposed to do from the user’s perspective, without specifying how it is implemented internally:
What a Clean Architecture Use Case (Interactor) is – and what it’s used for
In Clean Architecture, Use Case (Interactor) refers to a concrete application operation within the Application Layer. It orchestrates the work of multiple repository and service interfaces without handling UI or persistence details. In Android/Kotlin projects, the interactor typically encapsulates validation, mapping, transaction boundaries, and calls to room DAOs, retrofit services, or other gateways. This increases testability, infrastructure interchangeability, and domain model focus.
The abstraction boundary is crucial: An interactor implements application logic (e.g., “save a note while adhering to specific offline rules”), but not the UI or physical persistence. And it is not identical to a UML use case—even though the name might suggest otherwise. The similarity in names is historical/pragmatic, but in terms of content, Requirements (UML) and Application Operation (Clean Architecture) are distinct.
A consistent example from Android/Kotlin: “Save Note”
Let’s take the UML use case “Save Note”. From a business perspective, it only describes the goal: The user wants to save content to find it again later. How this happens internally—online, offline, with conflict resolution—is initially secondary and is captured narratively as scenarios/alternative flows.
In Clean Architecture, this is implemented through a UseCase (Interactor), here SaveNoteUseCase. It receives a command/request type with the required fields, validates the input, loads existing data if necessary, and orchestrates multiple Repository/Service calls. Depending on the architecture, a repository may access both a local room database and a retrofit HTTP service and choose between them (e.g., an offline-first strategy).
The PlantUML class diagram illustrates these roles and dependencies in a typical Android layered architecture:
From a developer’s perspective, this separation is worthwhile because UseCases (Interactors) form targeted, easily testable units: They can be tested in isolation using mock repositories without starting the UI or database. At the same time, the repository implementation remains free to combine multiple services—such as local caches, synchronization jobs, or feature flags—without cluttering the application logic.
Why the confusion is so common—and how to actively avoid it
The confusion is almost always a language problem. “Use Case” has been used as a UML term in requirements discourse for decades, while many clean architecture examples also call the central class UseCase. In business terms, this is a “What?” question; in technical terms, it’s “How does the application layer operate?”. Using the same terms for different levels often leads to scope drift in everyday practice: The business believes a business use case is “complete” as soon as an Interactor class exists in the code.
The antidote is consistent precision:
Always state the context in meetings and documents using: “UML use case” versus “Application-UseCase/Interactor”. In repositories, naming conventions help: Classes are named SaveNoteUseCase or, more clearly, SaveNoteInteractor. Requirements artifacts (e.g., tickets) have a prefix such as UC-42 Save Note. Link artifacts explicitly, e.g., in the README: “UML: UC-42” ↔ “Code: SaveNoteUseCase”.
Naming Suggestions – and Their Pitfalls
Many teams stick with XyzUseCase because tutorials and samples demonstrate it. This is legitimate as long as the glossary clearly states that the code refers to Application Use Cases (Interactors). Those who want to proactively avoid misunderstandings should name the classes XyzInteractor – semantically accurate, but initially unfamiliar. Alternatively, the intention can be expressed in the package name, for example, application/usecase/SaveNoteUseCase.kt.
For artifacts at the requirements level, plain text with an abbreviation is recommended, e.g., UC-Note-Save in Confluence/Jira. This keeps the UML meaning visible without conflicting with code artifacts. It is important to choose a convention and adhere to it consistently—in onboarding documentation, code reviews, and architectural decision-making (ADR).
A brief guide to establishing clear terminology
Start with a small glossary in the repository: “UML Use Case = business objective”; “Use Case (Interactor) = application operation in the application layer.” Link the UML use cases to their respective interactors. Clearly define package boundaries (presentation, application, domain, infrastructure) and keep interactors free of UI elements and physical persistence. In code reviews, domain rules should not be “extracted” into the interactors but delegated to domain models. And in meetings, the rule is: State the context first, then the action.
Conclusion
“Use case” is an overloaded term. In UML, it refers to requirements from the user’s perspective; in Clean Architecture, it stands (as an interactor) for application operations of the application layer. Both are useful—but only if we speak precisely and name things consciously. This keeps scope, responsibility, and quality crystal clear—and ensures smooth collaboration between product and engineering.