The 3-Layer Rule at Depth

The 3-layer rule is not just an organizational pattern. It is a load-bearing architectural decision that determines whether a module can be tested, maintained, and extended by people who did not write it. The three layers — presentation, logic, and data — must be independently replaceable. If you can swap the data layer from a file-based store to a database without touching the logic layer, the architecture is correct. If changing the data store requires rewriting business logic, you built a tent, not a building.

Layer one — presentation: everything the user or calling system sees. Input parsing, output formatting, error messages, response structure. This layer knows about the interface but knows nothing about how the data is stored. Layer two — logic: the business rules, transformations, and decision-making. This layer knows what to do with data but does not know where the data comes from or how the output is presented. Layer three — data: persistence, retrieval, external API calls, file operations. This layer knows how to get and store data but does not know what the data means or how it is used.

// Layer 1: Presentation — input/output interface
export function handleRequest(input: RawInput): FormattedOutput {
  const parsed = parseInput(input);       // presentation concern
  const result = processTask(parsed);     // delegates to logic
  return formatOutput(result);            // presentation concern
}

// Layer 2: Logic — business rules, no I/O
export function processTask(task: ParsedTask): TaskResult {
  const data = dataService.fetch(task.id); // delegates to data
  const analysis = applyRules(data, task); // pure logic
  return { analysis, confidence: score(analysis) };
}

// Layer 3: Data — persistence and retrieval
export const dataService = {
  fetch(id: string): StoredData { /* DB or file read */ },
  save(data: StoredData): void { /* DB or file write */ },
};