Robot's Clean Approach

Domain

Question: "Does this represent business meaning, rules, or invariants?" If yes → Domain.

Typical things here: - Entities - Value objects - Domain services - Domain events - Pure logic with no external dependencies

Your mental cue If it would still make sense in a console app with no UI, no database, no internet → Domain.

Application (Use Cases)=

Question: "Does this orchestrate domain logic to achieve a user‑level goal?" If yes → Application.

Typical things here: - Use case classes (e.g., LocateMissingTracks) - Input/output models for use cases - Interfaces for persistence, file access, external services - Transaction boundaries

Your mental cue If it coordinates domain objects but doesn't know how they're stored → Application.

Infrastructure

Question: "Does this talk to the outside world?" If yes → Infrastructure.

Typical things here: - EF repositories - File system access - HTTP clients - Logging implementations - Anything that touches OS, network, or frameworks

Your mental cue If it deals with how something is done (not what or why) → Infrastructure.

UI (or Presentation)

Question: "Does this exist only because humans need to see or interact with it?" If yes → UI.

Typical things here: - ViewModels - Commands - Data binding adapters - UI‑specific formatting - Brushes, colors, visual state logic

Your mental cue If it's about display, interaction, or state for the screen → UI.

🎯 The trick: When you're unsure, ask the dependency question If you're stuck on where something goes, ask:

> "What does this thing need to know about?"

- If it needs UI → it's UI. - If it needs infrastructure → it's infrastructure. - If it needs domain → it's application or domain. - If it needs nothing → it's domain.