These are 5 rules for writing better DTOs.

Ardalis' platform is a central hub for software developers, offering insights into software architecture, design patterns, and clean coding principles. Through articles, tutorials, and podcasts, Ardalis offers insights into building maintainable and scalable software applications. Developers can learn about SOLID principles, domain-driven design, and refactoring techniques to write high-quality code and design robust software architectures.

Ardalis

Learn the 5 rules for DTOs, including their purpose, ease of use, property usage, naming conventions, and specific use cases.

5 Rules for DTOs

I don’t fully agree with #4.
Sometimes one entity has multiple representations like ORM entities, read-only DTO-s for CQRS Read layer. They are named alike, because they represent same concept.
I think, that Dto suffix makes sense then, for easier to understand code.

Great to see that basics are still the best way!

I would like to add #6 - DTO ideally should be immutable to avoid data corruption while they are being passed (get; init; props).