Roles and policiesintermediate
Authentication is who you are; authorization is what you are allowed to do. Policies keep that rule in one place instead of scattered if-statements.
The layer everyone gets wrong. It orchestrates and authorises; it does not decide. Two kinds of validation live in two different places and both are needed.
Permissions are constants, the DTO validates the request, and the entity enforces the rules.
Published in full, before you start — every point is one of these and there is nothing else.
Authentication is who you are; authorization is what you are allowed to do. Policies keep that rule in one place instead of scattered if-statements.
Validation is telling the user what is wrong before they submit, in a way your server can trust too — a schema lets you write the rule once and use it in both places.
Splitting a system into layers only means something if the dependencies point one way — the rule that the DTO layer cannot see an entity is what stops your database schema quietly becoming your public API.