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.