ENGINEERING
Enterprise Backend Architecture
Designing the operational core of a business platform—from domain modelling and database architecture to APIs, workflows, and business rules.
Every application is only an interface. The backend is where business rules, workflows, permissions, and operational data are managed. It acts as the authoritative core of the platform, ensuring that every user works from the same operational reality.
Whether a booking is created through the website, assigned in the management workspace, or completed in the employee app, the backend coordinates every decision through one shared system.
Interactive backend architecture diagram
Cross-Cutting Concerns
Selected interface
Website
Customers create bookings through the website, but the backend validates business rules, stores operational data, and initiates the workflow.
Selected layer
API Layer
The HTTP boundary — 82 endpoints across 16 route groups. Every request is authenticated, authorized, and validated with Zod before it reaches any business logic, and controllers stay thin: they parse, validate, and delegate, never containing business rules themselves.
Business Domain Model
Business concepts become software architecture.
Every organisation is built around a set of core business concepts.
Instead of designing the backend around technical layers or database tables, CareOS is organised around business domains. Each domain represents a responsibility within the organisation and owns the data, rules, and workflows related to that responsibility.
This creates a backend that reflects how the business actually operates rather than how the software happens to be implemented.
How the business domains connect
How the domains connect
Operations
Manage bookings, planning, assignments, and service execution.
Responsible for
- Coordinating service delivery
- Scheduling work
- Managing visit execution
- Tracking operational status
Example business questions
- “Who will perform the visit?”
- “Has the booking been completed?”
- “Is the visit ready for settlement?”
These domains are a conceptual organisation of the business model, used to guide system design. The implementation is feature-oriented rather than domain-folder-based.
Business Entities
From business concepts to data structures.
Business domains define responsibilities. Business entities define the information each domain needs to manage.
People, organisations, bookings, visits, invoices, and payments already exist within the business. The database simply gives those concepts a consistent structure.
Rather than designing tables first, CareOS begins by identifying the real-world entities that make up the organisation.
Business domains and their entities
Selected entity
Bookings
Belongs to
Operations
Primary relationships
Business rules
- A booking must contain at least one booking item before it can be confirmed.
- A booking cannot be marked complete until every visit within it is completed.
- Cancelling a booking cancels every unstarted visit connected to it.
Example lifecycle
- Created
- Confirmed
- Planned
- Assigned
- Completed
- Settled
Entity Relationships
Relationships define the system.
A database is not a collection of isolated tables. Its value comes from the relationships between business entities. Understanding these relationships ensures that every workflow, report, and business rule is built upon a consistent representation of the organisation.
Interactive entity relationship diagram
Selected entity
Bookings
Represents a customer request for one or more services.
Connected to
Relationship summary
A booking belongs to one client, can contain multiple visits, may create invoices, and coordinates operational work.
Key message
A database is a network, not a spreadsheet.
Business software depends on connected information. Every relationship represents how the organisation operates in reality. The database succeeds because it models these relationships consistently across the platform.
Those relationships are physically expressed in a real, production database.
Database Architecture
Built on PostgreSQL. Structured for the business.
The database is not designed table-first. It is the physical expression of the business domains, entities, and relationships already defined above.
CareOS runs on managed PostgreSQL, accessed exclusively through Prisma. The schema has grown to 37 models and 17 enums across 25 migrations, with 144 indexes tuned for a multi-tenant access pattern. Concurrency-sensitive operations run inside serializable transactions with automatic retry, and tenant isolation is enforced in code rather than left to database-level row security.
The database, in numbers
Structure and scale, not assumptions.
Key message
The database enforces structure. The service layer enforces behaviour.
Constraints, indexes, and referential integrity keep the data itself correct. Everything about how that data changes — validation, business rules, audit trails — is deliberately kept out of the database and inside the platform's service layer, where it can be tested, versioned, and reasoned about like any other code.
The database enforces structure. Business services enforce behaviour.
Business Services
Business logic lives in services.
A relational database stores information, but services define behaviour.
Every important business operation—creating a booking, assigning an employee, generating an invoice, or completing a visit—is coordinated through business services. Each service applies business rules, validates information, updates related entities, and keeps the platform consistent.
Interactive business service explorer
Selected service
Booking Service
Creates and manages customer bookings.
Reads
- Clients
- Services
- Employee Availability
Updates
- Bookings
- Booking Items
Collaborates with
Example process
- Receive booking
- Validate client
- Create booking
- Schedule visit
- Notify downstream services
Key message
Services protect business rules.
Business rules should live in services rather than user interfaces or databases. Centralising behaviour keeps every application consistent, regardless of whether the request comes from the website, the management workspace, or the employee workspace.
Business services are exposed to every application through platform APIs.
Platform APIs
A single platform. Multiple applications.
Business services define behaviour. Platform APIs expose that behaviour to every application.
Rather than allowing each application to implement its own business logic, CareOS provides a shared interface between the frontend experiences and the backend services. This ensures that the website, management workspace, employee workspace, and future client portal all operate consistently on the same business rules.
Interactive platform communication diagram
Platform APIs
Business Services
Business Entities
Database
Selected application
Website
Accept customer enquiries and bookings, and present the service catalogue publicly.
Uses
- Booking API
- Service API
Business services
- Booking Service
- Service Catalog Service
Example interaction
- Customer submits booking
- Booking API
- Booking Service
- Booking created
- Confirmation sent
Key message
APIs expose capabilities, not databases.
Applications should communicate through well-defined platform interfaces rather than accessing data directly. This keeps business rules centralised and allows every frontend experience to evolve independently while sharing the same operational foundation.
Every layer above rests on a small set of architectural principles.
Architecture Principles
Design decisions that shape the platform.
Every architectural decision reflects a trade-off.
Rather than optimising for short-term implementation speed, CareOS is designed around principles that support long-term maintainability, consistency, and business evolution.
These principles guide every layer of the platform—from business modelling to application interfaces.
How the platform is layered
Key message
Architecture is an investment.
Well-designed systems are easier to understand, maintain, and extend. By aligning software structure with business structure, the platform remains resilient as organisations, teams, and requirements evolve.