Kurzfassung: „Anwendungsfall (Use Case)“ in der UML beschreibt fachliche Ziele und Nutzerwert – ein Requirements‑Artefakt. In der Clean Architecture bezeichnet ein UseCase (Interactor) eine Anwendungsoperation der Application Layer, die Repositories/Services orchestriert. Das sind unterschiedliche Abstraktionen mit unterschiedlichem Zweck. Wer beides sauber trennt, vermeidet Missverständnisse und Architektur‑Erosion.
Ein kurzes Missverständnis zur Einstimmung
PM: „Wir brauchen zwei neue Anwendungsfälle (Use Cases): Login und Notiz speichern." Entwickler: „Alles klar, ich lege zwei UseCases (Interactors) an und binde sie an die Repositories." Architekt: „Stopp – das eine sind UML‑Anwendungsfälle, das andere sind Application‑UseCases. Lasst uns präzise sein, sonst reden wir aneinander vorbei.“
Was ein UML‑Anwendungsfall (Use Case) tatsächlich ist
Wenn wir in der UML von einem Anwendungsfall (Use Case) sprechen, meinen wir eine fachliche Absicht aus Nutzersicht: ein Ziel, ein Wertversprechen, formuliert unabhängig von technischer Umsetzung. Ein Use Case umfasst typischerweise Akteure, ein Hauptszenario und Alternativflüsse (z. B. offline, fehlende Berechtigung). Sein Zweck ist Stakeholder‑Alignment, Scope‑Abgrenzung und Abnahmekriterien – nicht die Definition von Klassen, Repositories oder Datenbanken. Der UML‑Use Case ist somit ein Requirements‑Artefakt, kein Code‑Artefakt.
Die folgende PlantUML‑Skizze zeigt ein schlichtes Beispiel für eine Notiz‑App. Sie macht sichtbar, was das System aus Nutzerperspektive leisten soll, ohne Aussagen darüber, wie es intern realisiert wird:
Was ein Clean‑Architecture‑UseCase (Interactor) ist – und wozu er dient
In der Clean Architecture bezeichnet UseCase (Interactor) eine konkrete Anwendungsoperation innerhalb der Application Layer. Er orchestriert die Arbeit mehrerer Repository‑ und Service‑Schnittstellen, ohne sich um UI oder Persistenzdetails zu kümmern. In Android/Kotlin‑Projekten kapselt der Interactor typischerweise Validierung, Mapping, Transaktionsgrenzen und die Aufrufe an Room‑DAOs, Retrofit‑Services oder andere Gateways. Das erhöht Testbarkeit, Austauschbarkeit von Infrastrukturanbindungen und Fokus der Domänemodelle.
Wichtig ist die Abstraktionsgrenze: Ein Interactor implementiert Anwendungslogik (z. B. „Eine Notiz speichern und dabei spezielle Offline‑Regeln beachten“), jedoch nicht die UI und nicht die physische Persistenz. Und er ist nicht identisch mit einem UML‑Use Case – auch wenn der Name es suggeriert. Die Namensgleichheit ist historisch/pragmatisch, aber inhaltlich stehen sich Requirements (UML) und Application‑Operation (Clean Architecture) gegenüber.
Ein durchgehendes Beispiel aus Android/Kotlin: „Notiz speichern“
Nehmen wir den UML‑Use Case „Notiz speichern“. Aus fachlicher Sicht beschreibt er nur das Ziel: Die Nutzerin möchte Inhalte sichern, um sie später wiederzufinden. Wie das intern passiert – online, offline, mit Konfliktlösung – ist zunächst zweitrangig und wird narrativ als Szenarien/Alternativflüsse festgehalten.
Die Realisierung in Clean Architecture erfolgt durch einen UseCase (Interactor), hier SaveNoteUseCase. Er erhält einen Command/Request‑Typ mit den benötigten Feldern, validiert die Eingaben, lädt ggf. bestehende Daten und orchestriert mehrere Repository/Service‑Aufrufe. Ein Repository darf – je nach Architektur – sowohl auf eine lokale Room‑Datenbank als auch auf einen Retrofit‑HTTP‑Service zugreifen und zwischen beiden entscheiden (z. B. Offline‑First‑Strategie).
Die PlantUML‑Klassenskizze zeigt diese Rollen und Abhängigkeiten in einer typischen Android‑Schichtung:
Aus Entwicklersicht lohnt sich diese Trennung, weil UseCases (Interactors) zielgerichtete, einfach testbare Einheiten bilden: Man kann sie mit Mock‑Repositories isoliert prüfen, ohne UI oder Datenbank zu starten. Gleichzeitig bleibt die Repository‑Implementierung frei, mehrere Services zu kombinieren – etwa lokale Caches, Synchronisationsjobs oder Feature‑Flags – ohne die Application‑Logik zu verunreinigen.
Warum die Begriffsverwechslung so häufig ist – und wie man sie aktiv vermeidet
Die Verwechslung ist fast immer ein Sprachproblem. „Use Case“ wird im Requirements‑Diskurs seit Jahrzehnten als UML‑Term verwendet, während viele Clean‑Architecture‑Beispiele die zentrale Klasse ebenfalls UseCase nennen. Fachlich meint das eine „Was?“-Frage, technisch das „Wie wird die Anwendungsschicht tätig?“. Dieselben Worte für unterschiedliche Ebenen führen im Alltag zu Scope‑Drift: Das Business glaubt, ein fachlicher Anwendungsfall sei „fertig“, sobald eine Interactor‑Klasse im Code existiert.
Gegenmittel ist konsequente Präzision:
Formuliere in Meetings und Dokumenten stets den Kontext mit: „UML‑Anwendungsfall“ versus „Application‑UseCase/Interactor“. In Repositories helfen Naming‑Konventionen: Klassen heißen SaveNoteUseCase oder deutlicher SaveNoteInteractor. Requirements‑Artefakte (z. B. Tickets) tragen ein Prefix wie UC-42 Notiz speichern. Verknüpfe Artefakte explizit, z. B. im Readme: „UML: UC‑42“ ↔ „Code: SaveNoteUseCase“.
Benennungsvorschläge – und ihre Tücken
Viele Teams bleiben bei XyzUseCase, weil Tutorials und Samples es so vormachen. Das ist legitim, solange das Glossar klar festhält, dass es sich im Code um Application‑UseCases (Interactors) handelt. Wer Missverständnisse proaktiv vermeiden will, benennt die Klassen XyzInteractor – semantisch treffend, aber zunächst ungewohnt. Alternativ kann man die Absicht im Paketnamen ausdrücken, etwa application/usecase/SaveNoteUseCase.kt.
Für Artefakte auf Requirements‑Ebene empfiehlt sich Klartext mit Kürzel, z. B. UC-Notiz-Speichern in Confluence/Jira. So bleibt die UML‑Bedeutung sichtbar, ohne mit Code‑Artefakten zu kollidieren. Wichtig ist, eine Konvention zu wählen und sie durchzuhalten – in Onboarding‑Docs, Code‑Reviews und Architekturentscheidungen (ADR).
Ein kurzer Leitfaden zur Etablierung klarer Begriffe
Beginne mit einem kleinen Glossar im Repository: „UML‑Anwendungsfall (Use Case) = fachliches Ziel“; „UseCase (Interactor) = Anwendungsoperation in der Application Layer“. Verlinke die UML‑Use‑Cases mit den jeweiligen Interactors. Lege Package‑Grenzen sichtbar fest (presentation, application, domain, infrastructure) und halte Interactors frei von UI und physischer Persistenz. In Code‑Reviews sollten Domain‑Regeln nicht in die Interactors „auslaufen“, sondern an Domain‑Modelle delegiert werden. Und in Meetings gilt: Kontext zuerst nennen, dann die Maßnahme.
Fazit
„Use Case“ ist ein überladener Begriff. In der UML bezeichnet er Requirements aus Nutzersicht; in der Clean Architecture steht er (als Interactor) für Anwendungsoperationen der Application Layer. Beides ist sinnvoll – aber nur, wenn wir präzise sprechen und bewusst benennen. So bleiben Scope, Verantwortung und Qualität messerscharf – und die Zusammenarbeit zwischen Produkt und Engineering entspannt.