Layer separation: data, logic, and UI

Layer separation is keeping the data, the logic, and the interface in their own zones so each can change on its own. The data holds your records, the logic decides what happens to them, and the user interface (UI) is how you see and act on them.

Layer separation is keeping the data, the logic, and the interface in their own zones so each can change on its own. The data layer holds your records, the logic layer decides what happens to them, and the user interface (UI) layer is how you see and act on them. Picture a personal task system. The data layer is the list of tasks with their due dates and status; the logic layer is the rule that flags anything overdue and sorts the rest by priority; the UI layer is the screen that shows today's tasks and the button you tap to mark one done. Because the three stay apart, you can redesign the screen without touching how overdue tasks are flagged, and you can change the flagging rule without moving a single record. The principle has a name, separation of concerns, which the computer scientist Edsger Dijkstra described in 1974.

Builder example

When you ask an AI assistant to restyle one screen and it instead rewrites the rules that decide what counts as done, the layers were tangled together in one place. Telling the assistant to keep data, logic, and UI in separate files means a visual change stays a visual change, so a request to enlarge headings on your daily task view does not quietly alter how overdue items get flagged. It also lets you swap where records live, say from a spreadsheet to a folder of files, while the screen and the rules keep working untouched.

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.