NovaTrek Domain Model¶

This page describes the business domain that the NovaTrek architecture serves. Understanding the domain is a prerequisite for producing architecturally sound solution designs.

What NovaTrek Does¶

NovaTrek Adventures is an outdoor adventure company that operates guided trips — hiking, rock climbing, kayaking, wildlife tours, and 21 other adventure categories. The platform manages the full lifecycle: guests browse and book adventures, check in on the day of their trip, receive safety briefings and gear, and participate in guided experiences.

Service Domains¶

The platform is decomposed into 9 bounded contexts, each owning a set of microservices.

Bounded Context Rules¶

These rules are non-negotiable. Every solution design must respect them.

1. Services within the same domain may share data types but MUST communicate via API contracts
2. Cross-domain communication MUST go through published API endpoints — never direct database access
3. Each service owns its data exclusively — no shared databases between services
4. Event-driven integration is preferred between domains; synchronous REST within a domain is acceptable
5. svc-check-in is the designated orchestrator for all day-of-adventure workflows
6. svc-scheduling-orchestrator owns the schedule lifecycle — other services MUST NOT mutate schedule data directly
7. Guest identity resolution always flows through svc-guest-profiles — services MUST NOT maintain shadow guest records

Data Ownership¶

Every data entity has exactly one owning service. Other services access it read-only through APIs.

When designing a solution, always verify data ownership boundaries. If your design requires Service A to write data owned by Service B, you have a boundary violation that needs to be resolved — typically through an API call to Service B or an event-driven pattern.

Adventure Classification System¶

NovaTrek classifies 25 adventure categories into 3 check-in UI patterns. This classification drives safety workflows, gear assignment, and staffing requirements.

The classification is configuration-driven (ADR-004), meaning new adventure categories can be added to config/adventure-classification.yaml without code changes. The classification engine reads this YAML at runtime.

Integration Patterns¶

Synchronous (REST)¶

Used for real-time operations within bounded contexts and for cross-domain reads where latency matters:

• Check-in service calling guest profiles to verify identity
• Scheduling orchestrator reading guide availability
• Reservations service looking up trip catalog details

Asynchronous (Kafka Events)¶

Used for cross-domain state propagation where eventual consistency is acceptable:

• Check-in completion triggers gear preparation notification
• Reservation confirmation triggers schedule slot allocation
• Safety waiver expiration triggers guest notification

See the Event Catalog for the full list of domain events, producers, and consumers.

Orchestration vs. Choreography¶

• svc-check-in uses the orchestrator pattern for day-of-adventure workflows — it coordinates the sequence of calls to guest profiles, reservations, safety compliance, and gear inventory (ADR-006)
• Cross-domain integration uses choreography via Kafka events — no central coordinator; each domain reacts to events independently

Frontend Applications¶

Three frontend applications consume the microservice APIs:

Wireframes for these applications are maintained as Excalidraw files in architecture/wireframes/. See Diagrams and Wireframes for how to edit them.

Key Architecture Decisions¶

These global decisions constrain the design space. Read them before proposing solutions.