The team changes how orders are stored. The customer should not care which database technology sits behind checkout. Yet suddenly the UI needs changes, discount rules need retesting and the whole payment journey is affected. Different reasons for change have become unnecessarily entangled.
Layered architecture tries to separate responsibilities inside an application. Its value is not the number of boxes on a diagram. It is the ability to change one concern without rebuilding everything around it.
Where useful boundaries live
An application might separate the interface, application workflows, domain rules and data access. The UI presents actions to the user. The application layer coordinates a use case. Domain rules decide whether a discount or a status change is valid. Data access handles the mechanics of persistence.
Real applications use different names and numbers of layers. What matters is that a business rule should not accidentally depend on an HTTP request format or today's database schema.
Do the layers need separate teams?
No. Layers are architectural boundaries, not an instruction to organise people into technology departments. If each tiny feature must wait for the UI team, then the services team, then the database team, the architecture may increase coordination costs.
It is usually better for a team to own a customer-facing flow end to end while respecting appropriate internal boundaries. Layers do not remove responsibility for the complete checkout experience.
When layering turns into overhead
It is easy to overdo the pattern. To read one field, a request passes through five classes that merely forward arguments. That is not protection of domain logic; it is the cost of maintaining a picture.
Some read paths need to be optimised differently from the write model. Some products are small enough that a few clear modules are simpler than an elaborate layered structure. Measure the cost of changing behaviour, not the number of interfaces.
How I would test whether it works
Look at recent substantial changes. How many unrelated areas were touched for one business request? Where did regressions appear? Can the discount calculation be tested without starting external infrastructure? Those observations reveal the value of boundaries better than a slide.
Check dependency direction as well. If domain rules depend directly on technical adapters, infrastructure changes can still ripple into the core. In that case Ports & Adapters may offer a useful comparison, without becoming another mandatory fashion.
A good layer costs less than the coupling it removes. If its main contribution is to make every change travel farther, the business is not winning.