The service declaration is the architectural starting point of a Carrier application. It defines the unit being built and gives the rest of the source a boundary.
In enterprise architecture, boundaries are not just technical — they express ownership. A service boundary should answer: what business capability does this service own? What data is it responsible for? Which workflows belong here? Which workflows belong elsewhere? Which teams depend on this API? Which policies govern access? Carrier cannot answer those questions automatically. But it gives the organization a place to encode the answers.
Services as Bounded Contexts
A good Carrier service often maps to a bounded context — a domain area with its own language, rules, lifecycle, and data responsibilities. In a healthcare system, patient registration and clinical documentation may both involve patient data, but they may not belong to the same service. Registration focuses on identity, demographics, and administrative workflow. Clinical documentation focuses on encounters, observations, notes, questionnaires, and care events.
Combining these concerns may seem convenient at first, but it can produce unclear ownership. Splitting them too aggressively can produce excessive integration cost. Enterprise architects must choose boundaries that match real operating responsibility. Carrier supports either style, but it rewards clarity.
What Belongs Inside a Service
A Carrier service should contain the concepts it owns directly: models for data the service persists, types for request and response contracts, actions for domain behavior, routes for external access, policies for access and visibility, and jobs, events, schedules, and clients when needed.
What should not belong inside the service is equally important. A service should not become a dumping ground for every workflow that touches its data. If another domain owns the business decision, the integration should respect that ownership.
Application Boundary vs Deployment Boundary
A Carrier service boundary does not always have to equal an enterprise deployment boundary. Some organizations may deploy one Carrier service per runtime unit. Others may use Carrier to structure a modular service that is still deployed together. The architectural question is ownership first, deployment second.
Protects data through explicit policies
Minimizes unnecessary imports from unrelated domains