Layer separation: data, logic, and UI

Separating data ownership, domain rules, and interface concerns behind explicit boundaries so changes have a smaller, testable effect.

A task system may store records through a repository, calculate overdue status in domain logic, and render that state through a UI. The boundaries need contracts for reads, writes, errors, and state changes. They need not map one-to-one to files or processes, and changing storage can still require schema and performance work elsewhere.

Builder example

Clear boundaries let tests exercise rules without a browser and let UI changes reuse established domain operations. They also give an agent a smaller authorized surface. A visual request should not require rewriting completion semantics, though shared types or accessibility behavior may legitimately cross layers.

Common confusion: Separating layers is about where each kind of work lives, not about how many files you have. What makes a system layered is that the records, the decision rules, and the display each sit in their own zone and change independently; splitting one tangled file into three that still reach into each other leaves the layers as mixed as before.