Why: the goal or problem

Imagine a library guide where readers save borrowing rules from web or CLI. Page-owned validation duplicates rules; the team wants a simple presentation–application–storage path.

How: work toward a solution

  1. One process: reader Jun, Borrowing Rules unsaved; memory or embedded database.
  2. HTTP or CLI presentation imports and calls application validation, which imports and calls persistence. No layer skipping.
  3. Saved returns upward: 0 → 1 entries; repeat → 1. Empty IDs or failure before writing → 0; retry after correction.

Switching HTTP to CLI leaves validation in place.

Logical layers can share one deployment

Illustrative example

Three responsibilities, one process

Jun wants to save the Borrowing Rules page · initially unsaved

One process · dotted enclosure

  1. Presentation

    HTTP / CLI

    Receives IDs; displays Saved

    Source dependency ↓

    Runtime call ↓

  2. Application

    SaveArticle(Jun, Borrowing Rules)

    Validates IDs; coordinates saving

    Source dependency ↓

    Runtime call ↓

  3. Persistence

    Memory / Embedded database

    Records one saved entry

↑ Saved returns: persistence → application → presentation

Closed-layer example: no skipping. Replace HTTP with CLI; validation stays in the application.

  • Save → repeat: 0 → 1 → 1 entries; return Saved.
  • From empty: empty IDs or failure before writing → 0. Retry after correction.

HTTP / CLI and memory / embedded database are alternatives; no data migration is implied.

These logical layers share one process and release. A process failure can affect all three; the arrows are not network links.

What: the concept

Layered architecture separates responsibilities and constrains dependencies. Logical layers need not be separate machines. Microsoft

Pass-through layers add ceremony. Ports can invert storage dependencies. Folder names alone enforce nothing.