How would you design request DTOs for an ASP.NET Core endpoint, and why not bind directly to domain or EF entities?

In production I design separate create, replace, and patch inputs because they have different absence and ownership semantics. Server-owned identity, audit, tenant, role, price, and workflow-state fields never become bindable merely because they exist on an entity. DTO mapping creates an explicit review point for normalization and authorization-sensitive choices, while application commands express the use case without HTTP attributes. I evolve request contracts additively where possible and use contract tests to prevent accidental field exposure during refactors. For partial updates I represent omitted versus explicit null deliberately rather than relying on CLR defaults or a large reusable DTO.