Context map

Baseleg is organized into bounded contexts. Each context owns a slice of the domain with its own model, language, and rules — even when contexts reference the same real-world entity (e.g. a person appears in People, Scheduling, and Training, but each context holds only the fields it needs).

Bounded contexts

People

Manages identity and roles within the organisation. The canonical source of truth for who exists in the system.

• Package: packages/domain/people, packages/application/people
• Aggregate root: Member
• Key concepts: Member, Student, Instructor, Staff

Aircraft

Manages the fleet and its operational state. The canonical source of truth for what aircraft exist and whether they are available.

• Package: packages/domain/aircraft, packages/application/aircraft
• Aggregate root: Aircraft
• Key concepts: Aircraft, Grounded, Registration

Scheduling

Manages time-based allocation of aircraft and instructors. Enforces booking rules and prevents conflicts.

• Package: packages/domain/scheduling, packages/application/scheduling
• Aggregate root: Booking
• Key concepts: Booking, TimeRange, Conflict

Training (v1 lite)

Records training activity and progression for students.

• Package: packages/domain/training, packages/application/training
• Key concepts: Lesson, Flight, Endorsement

Billing (v1 lite)

Tracks charge items and manages the invoice lifecycle.

• Package: packages/domain/billing, packages/application/billing
• Key concepts: Charge Item, Invoice Draft, Invoice

Compliance (v1 lite)

Monitors currency requirements and produces compliance alerts.

• Package: packages/domain/compliance, packages/application/compliance
• Key concepts: Currency, Compliance Alert, Document Expiry

Notifications (adapter context)

Delivers communication events from other contexts to external channels (email, SMS, in-app).

• Package: packages/domain/notifications, packages/application/notifications
• Key concepts: Notification, Channel, Delivery

Reporting (v1 lite)

Produces operational summaries and exports from data across contexts.

• Package: packages/domain/reporting, packages/application/reporting
• Key concepts: Report, Export, Summary

---

v1 product spine

The v1 spine focuses on the three primary contexts:

People ──── Scheduling ──── Aircraft
  │               │
  └── Training    └── Billing / Compliance / Notifications / Reporting
        (lite)              (lite)

1. People — who can book
2. Aircraft — what can be booked
3. Scheduling — when, and with what constraints

Training, Billing, Compliance, Notifications, and Reporting are intentionally lite until the spine is reliable.

---

Cross-context relationships

Contexts are kept loosely coupled. When a context needs data from another, it holds only the minimum identifier or read-model needed — it does not import the other context’s domain package.

From	To	What is shared
Scheduling	People	Member ID (booking owner, instructor reference)
Scheduling	Aircraft	Aircraft ID + availability/grounded state
Training	People	Member ID (student, instructor references)
Training	Scheduling	Booking ID (optional link from lesson to booking)
Billing	Scheduling	Booking ID (charge items linked to bookings)
Billing	People	Member ID (invoice recipient)
Compliance	People	Member ID (currency requirements per member)
Compliance	Aircraft	Aircraft ID (airworthiness documents)
Notifications	All	Event payloads from other contexts
Reporting	All	Read-model queries (infrastructure layer only)

Cross-context coupling should always be through identifiers or read-models — never through domain object references.