Carrier is built around a simple architectural idea: enterprise services should describe their domain shape directly. The important parts of a service should not be buried across framework code, middleware, migration scripts, annotations, and handwritten documentation.
Domain-First Service Design
Carrier encourages teams to begin with the domain, not the framework. A Carrier service should represent a clear business capability: patient intake, claims processing, appointment scheduling, consent management, inventory control, billing, identity, or another coherent area of ownership. The central question is not which endpoints do we need? but what responsibility does this service own?
Thin Routes, Rich Actions
Carrier separates HTTP edge behavior from business behavior. Routes own HTTP concerns: path, method, request body, response shape, authentication, and edge semantics. Actions own business behavior — the right place for reusable operations, transactional logic, auth-aware workflows, and domain decisions.
Declarative Contracts Over Framework Plumbing
Enterprise teams spend too much time re-creating the same service structure. Carrier does not eliminate implementation detail, but it raises the level of expression. Models, types, routes, actions, and policies become first-class declarations. That shift matters because declarations can be inspected — they can generate artifacts, feed governance workflows, and be checked before runtime.
Compile-Time Structure as Governance
Carrier makes more of the architecture visible to tools. When the service shape is declared, the toolchain can generate OpenAPI, migrations, runtime code, and manifest metadata. This allows enterprise architecture to move from after-the-fact review toward earlier, automated inspection.
Service structure should be explicit enough for both developers and architects to trust.