Verified:GitHub

dto-schema-design

Design versioned DTO transfer contracts with strict validation and allowlisted mapping.

4|Updated May 16, 2026

Search Tags:#compatibility #validation rules #api contract #schema versioning #dto schema #nullability semantics #mass assignment defense

Ready to run

npx skills add https://github.com/machenjie/rd-skills --skill dto-schema-design

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: dto-schema-design
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/dto-schema-design
Command: npx skills add https://github.com/machenjie/rd-skills --skill dto-schema-design

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

DTO schema design keeps your external API, event, and integration contracts stable while preventing internal model changes from breaking clients and introducing security risks like mass assignment.

Core Features & Use Cases

Versioned, contract-first schemas for requests and responses with explicit field types, nullability semantics, defaults, and forward-backward compatibility rules.
Validation and safety guardrails including strict additionalProperties policies for request DTOs and clear rejection of unknown fields.
DTO-to-domain mapping discipline using explicit field allowlists to ensure validation occurs before domain logic and internal models never leak to API layers.

Quick Start

Ask the assistant to produce a versioned request/response DTO schema that clearly distinguishes null vs absent semantics, enforces strict input validation, and includes an allowlisted mapping strategy to the domain command.

Frequently Asked Questions about dto-schema-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I design DTO schemas that prevent mass assignment and internal model leakage?▼

To design DTO schemas that prevent mass assignment, enforce strict request schemas with additionalProperties false and use explicit field allowlists for DTO-to-domain mapping. This ensures validation occurs before domain logic and internal models never leak to API layers.

What is the best way to handle null vs absent field semantics in API contracts?▼

Handling null vs absent field semantics in API contracts requires documenting four-state behavior (null, absent, empty, present) within versioned DTO schemas. This explicitly defines field types and nullability to preserve forward-backward compatibility across HTTP and gRPC payloads.

How do I evolve API contracts without breaking existing clients?▼

To evolve API contracts without breaking clients, apply additive-only minor evolution rules to versioned DTO schemas. This decouples external API shapes from internal domain models while preserving compatibility for request and response bodies.

When do I need strict DTO schemas with additionalProperties false for request validation?▼

You need strict DTO schemas with additionalProperties false for request validation when building HTTP or gRPC APIs that must reject unknown fields. This guardrail prevents mass assignment vulnerabilities and ensures only explicitly defined fields enter domain logic.

Can I use explicit DTO-to-domain mapping for CQRS view projections and event payloads?▼

Yes, explicit DTO-to-domain mapping applies to CQRS view projections and event payloads by using assemblers, converters, and mappers. This decouples external transfer shapes from internal persistence models while enforcing validation and nullability semantics.

What are the limitations of relying solely on internal domain models for API responses?▼

Relying solely on internal domain models for API responses causes internal model leakage and client breakage during model changes. Without explicit versioned DTO contracts, you lose forward-backward compatibility and expose mass assignment security risks.