Establish project architecture and design decisions
This commit is contained in:
@@ -0,0 +1,38 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user