القائمة
Thin Sequel::Model wrappers — no business logic, no domain knowledge
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
How orm/ and repositories/ split responsibility in app/infrastructure/database/
| name | orm |
| description | Thin Sequel::Model wrappers — no business logic, no domain knowledge |
orm/ holds the thinnest possible Sequel::Model subclasses. They exist to
configure table mapping and Sequel plugins — nothing more.
*Orm, module path Tyla::Database::*OrmSequel::Model(:table_name), plugin :timestamps,
associations (one_to_many, etc.), and the validations Sequel itself needs
to enforce DB invariantsallowed?, expired?), no
formatters, no derived columns. Anything that is not "this is the DB
shape" belongs in an entity, a value object, or a serviceapp/infrastructure/database/ must not reference these
classes directly — they go through a repositoryIf you find yourself wanting to add a method here, ask: does this belong on the domain entity, the repository, or the service?