39 lines
1.1 KiB
Markdown
39 lines
1.1 KiB
Markdown
# ADR 0006: Use Pydantic for Domain Models
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The application manages structured and versioned entities such as meetings,
|
|
recordings, transcripts, participants and AI-generated artifacts.
|
|
|
|
These entities must be:
|
|
|
|
- type-safe
|
|
- validated at runtime
|
|
- serializable to JSON
|
|
- loadable from persisted JSON
|
|
- independent of the storage implementation
|
|
|
|
Python dataclasses provide a lightweight representation but do not provide
|
|
the required validation and serialization behavior without additional code.
|
|
|
|
## Decision
|
|
|
|
The project will use Pydantic models for its domain model.
|
|
|
|
Domain models shall inherit from a shared project base model.
|
|
|
|
Storage-specific behavior, database access and processing logic must not be
|
|
implemented inside the domain models.
|
|
|
|
## Consequences
|
|
|
|
- Invalid data can be rejected at module boundaries.
|
|
- Domain objects can be serialized to and restored from JSON.
|
|
- JSON schemas can be generated for interfaces and documentation.
|
|
- Pydantic becomes a core project dependency.
|
|
- Domain models remain independent of the eventual storage backend.
|