Domain

Baseleg uses Domain-Driven Design (DDD) as its primary modelling approach. This section describes the domain model, bounded contexts, and the ubiquitous language that all contributors should use.

Why DDD for Baseleg

Aviation operations have rich, well-understood business rules: aircraft can only be booked when available, instructors cannot be double-booked, a member’s compliance currency determines what they can legally fly. These rules are non-trivial, and the wrong architecture (business logic scattered across UI handlers or raw SQL) leads to bugs that erode trust.

DDD gives us a disciplined way to:

• Encapsulate business rules in domain packages that are independent of frameworks and databases.
• Name things correctly using the ubiquitous language of the aviation domain.
• Separate concerns through bounded contexts, so each capability evolves independently.

Bounded contexts

The domain is divided into eight bounded contexts. Each context:

• Has its own domain package (packages/domain/<context>/) containing entities, value objects, and domain rules.
• Has its own application package (packages/application/<context>/) containing use cases.
• Shares infrastructure implementations (DB, notifications) via ports.

Context	Status	Purpose
People	v1 primary	Members, students, instructors, staff
Aircraft	v1 primary	Fleet, airworthiness state, grounded protection
Scheduling	v1 primary	Bookings, conflict detection, calendar
Training	v1 lite	Lessons, flights, endorsements
Billing	v1 lite	Charge items, invoice drafts
Compliance	v1 lite	Currency tracking, compliance alerts
Notifications	v1 lite	Email, SMS, in-app delivery
Reporting	v1 lite	Operational reports and exports

Layered package structure

Each bounded context follows the same layering:

packages/
  domain/<context>/          ← entities, value objects, domain rules
  application/<context>/     ← use cases, orchestration

Infrastructure implementations (repositories, adapters) live in packages/infrastructure/ and wire against ports defined by the application layer.

See Architecture for full package boundary rules.

Ubiquitous language

All code, documentation, and conversations should use the domain language defined in Ubiquitous Language. Using the correct terminology reduces ambiguity and keeps the codebase aligned with the business model.

How to navigate

• New to the domain? Start with the Context Map for a high-level view of how the contexts relate.
• Adding a feature? Find the relevant bounded context page via the Context Map for its entities, rules, and use cases.
• Unsure about a term? Check the Ubiquitous Language reference.