メニュー
How orm/ and repositories/ split responsibility in app/infrastructure/database/
| name | infrastructure-database |
| description | How orm/ and repositories/ split responsibility in app/infrastructure/database/ |
Two sublayers, two jobs:
app/infrastructure/database/
├── orm/ ← thin Sequel models, no business logic
└── repositories/ ← maps ORM rows ↔ domain entities, owns DB queries
| Layer | Knows about | Returns | Allowed to contain |
|---|---|---|---|
orm/ | Sequel + schema | ORM model instances | Sequel::Model(:table), plugins, associations |
repositories/ | ORM + domain entities | Domain entities | Query construction, entity (re)building |
repositories/ → orm/
repositories/ requires / uses orm/ classes.orm/ must NOT import repositories/, services, controllers, or anything
upstream.repositories/. They must not reference Database::*Orm directly.The ORM model knows the database. The Repository knows the domain. If callers were allowed to touch the ORM directly, the schema would leak into services and controllers, and swapping persistence would touch every caller.
See sublayer details in:
Request contracts validate input AND map external API names onto domain entities
Domain-Driven Design architecture patterns and conventions for this project
Roar::Decorator representers that turn domain entities into JSON
Presentation layer serializes domain entities to wire formats (JSON, etc.)
Repository pattern for translating between ORM rows and domain entities
When to use Dry::Struct DTO entities vs. plain Ruby class entities in domain/entities/