Architecture

Gryd.IO splits reusable behavior into Domain, Application, Infrastructure and API packages. Dependencies should point toward contracts and domain behavior; adapters and ASP.NET composition stay at the outside edge.

• Domain: entities, value objects, events and domain contracts.
• Application: use cases, CQRS messages, validation and service abstractions.
• Infrastructure: persistence, caches, storage and external providers.
• API: ASP.NET controllers, middleware, routing, versioning and OpenAPI integration.

Module meta-packages compose these layers for convenience. Applications needing tighter dependency control can reference layer packages individually. Cross-module behavior should use documented contracts or events instead of service location.

See the package catalog for the actual package boundaries and the ADR index under docs/adr/ for decisions that constrain Auth and tenant scoping.