Data Transfer Objects (DTOs)
DTOs are simple data containers that define the input and output boundaries of use cases. They decouple the application layer from external concerns and provide clear contracts for data exchange.Purpose
DTOs in Soft-Bee API serve to:- Define clear boundaries between layers
- Validate input data before it reaches business logic
- Prevent exposure of internal domain models to external layers
- Provide type safety and automatic validation
- Enable easy serialization/deserialization for APIs
Implementation
Soft-Bee uses Pydantic for DTOs, providing automatic validation and documentation:Authentication DTOs
Authentication feature DTOs are located insrc/features/auth/application/dto/auth_dto.py:1
Login Request DTO
email: Must be valid email format (PydanticEmailStr)password: Required, minimum 1 characterremember_me: Optional boolean, defaults toFalse
Login Response DTO
access_token: JWT token for API authenticationrefresh_token: Token for refreshing access tokentoken_type: Always “bearer” for JWTexpires_in: Token expiration time in secondsuser: User details (id, email, username, verification status)
Register Request DTO
src/features/auth/application/dto/auth_dto.py:19
Purpose: Validates new user registration data.
Validation Rules:
email: Valid email formatusername: 3-50 characters, alphanumeric plus underscores onlypassword: Minimum 8 charactersconfirm_password: Must match password field
validate_username- Ensures username contains only allowed characterspasswords_match- Verifies password confirmation matches
Register Response DTO
id: Unique user identifieremail: User’s email addressusername: Chosen usernameis_verified: Email verification status (typicallyFalsefor new users)created_at: Account creation timestampmessage: Success message
Token Management DTOs
Refresh Token Request DTO
Refresh Token Response DTO
Logout Request DTO
Verify Token Request/Response DTOs
DTO Design Principles
1. Separation of Concerns
DTOs are distinct from domain entities:2. Input Validation
Pydantic validators ensure data integrity before reaching use cases:3. Type Safety
Strong typing prevents runtime errors:4. Self-Documenting
Field descriptions provide API documentation:DTO Usage Pattern
Typical flow from API request to use case:Benefits
- Validation at the Edge - Invalid data never reaches business logic
- Clear Contracts - Explicit input/output expectations
- Testability - Easy to create test data
- Documentation - Self-documenting API contracts
- Versioning - Can evolve DTOs without changing domain
- Framework Independence - Business logic doesn’t depend on Flask/FastAPI
Best Practices
- Keep DTOs Simple - No business logic, only data and validation
- One DTO per Operation - Don’t reuse DTOs across different operations
- Validate Early - Use Pydantic validators for all constraints
- Descriptive Names - Use
RequestandResponsesuffixes - Optional Fields - Provide sensible defaults where appropriate
- Documentation - Add field descriptions for API documentation
See Also
- Use Cases - Business logic that uses DTOs
- API Reference - How DTOs map to REST endpoints
- Domain Exceptions - Validation error handling