Separation of concerns divides an application so different parts own different kinds of decisions. A layer is useful when it creates a meaningful boundary, not merely because every project is expected to have the same folders.

A typical application may separate responsibilities such as

interface or transport → application workflow → domain rules
                                  ↓
                         persistence / infrastructure

The exact layers depend on the application. A command-line tool, desktop program and network service expose different outer interfaces, but all benefit when business decisions are not needlessly mixed with presentation, storage or transport details.

An application or service layer can coordinate a use case that spans several domain operations, transactions or external effects. A function that merely forwards the same arguments to another component adds indirection without creating a useful boundary.

Infrastructure code owns details such as databases, files, network clients or external services. Higher-level policy should interact with those details through boundaries that expose the capabilities it actually needs.

Not every operation needs every layer. Good layering follows responsibilities and change boundaries: it keeps decisions that change for different reasons apart while avoiding ceremonial abstractions that add no independence.