Bounded Context & System Boundaries

The Fitness (GYM) domain operates as an autonomous operational bounded context within the Obelaw enterprise ecosystem. It establishes explicit linguistic and systemic boundaries around membership agreements, freeze and suspension lifecycles, class scheduling and booking, turnstile access governance, personal training credit operations, and member progress engagement.

Maintaining clean boundaries ensures that contract integrity, capacity guarantees, and access decisions are shielded from generic invoicing mechanics, marketing automation, payroll processing, and vendor-specific access hardware protocols.

---

1. Subdomain Classification & Strategic Investment

Applying the strategic classification methodology from Vlad Khononov’s Learning Domain-Driven Design, the capabilities associated with running a modern fitness business are partitioned based on business differentiation and systemic complexity:

flowchart TD
    subgraph CoreDomain["Core Domain: High Complexity & Strategic Differentiation"]
        MembershipLifecycle["Membership & Subscription Lifecycle Engine"]
        FreezeMachine["Freeze & Suspension State Machine"]
        BookingOrchestration["Class Capacity, Booking & Waitlist Orchestration"]
        AccessGovernance["Access Control & Check-in Decision Engine"]
    end

    subgraph SupportingDomain["Supporting Domain: Custom Operational Capabilities"]
        TrainerOps["Trainer & Personal Training Session Management"]
        StrikeEngine["Strike & Booking Privilege Policy Enforcement"]
        EngagementTracking["Workout Programming & Member Progress Tracking"]
        FacilityTopology["Club, Zone & Studio Schedule Topology"]
    end

    subgraph GenericDomain["Generic Domain: Standardized / Off-the-Shelf Integration"]
        MemberMaster["Member Identity & Demographics (CRM)"]
        RecurringBilling["Recurring Invoicing, Payments & Dunning (Accounting/FMS)"]
        NotificationDispatch["SMS / Email / Push Notification Delivery"]
        AccessHardware["Turnstile & Scanner Hardware Firmware"]
        TrainerPayroll["Staff Contracts & Payroll (HCM)"]
    end

    CoreDomain -.->|Coordinates with| SupportingDomain
    SupportingDomain -.->|Integrates via ACL / Events with| GenericDomain

Strategic Classifications Explained

• Core Domain: The membership lifecycle engine, freeze state machine, booking and waitlist orchestration, and the access decision engine represent the club’s primary competitive advantage and revenue protection zone. These capabilities directly determine who may train, when, and under what contractual standing — they require custom, high-fidelity tactical DDD modeling.
• Supporting Domain: Trainer session management, strike policy enforcement, workout programming, and facility topology complement the core workflows. They are custom-built to support fitness operations without defining the primary business differentiator.
• Generic Domain: Generic enterprise problems (recurring invoicing, notification delivery, identity management, payroll, hardware firmware) are delegated to external or platform contexts. The Fitness context integrates with them via formal Anti-Corruption Layers (ACL) and domain event contracts.

---

2. In-Scope Operational Capabilities

The Fitness bounded context is strictly responsible for the following operational workflows:

• Membership Plan & Tier Catalog: Definition of sellable membership plans (monthly, annual, off-peak, student, corporate), access tiers governing zone entitlements, joining fees, commitment periods, freeze quotas, and advance booking windows per tier.
• Membership Agreement Lifecycle: Activation, billing cycle anchoring, plan upgrades and downgrades with proration intent, auto-renewal, expiry, voluntary cancellation with notice periods, and involuntary termination.
• Freeze & Suspension Management: Member-initiated freezes with start and end dates, day-for-day expiry extension, annual freeze quota enforcement, early resume, and payment-failure suspension with cure-based reactivation.
• Class Catalog & Scheduling: Recurring class templates (category, duration, difficulty, default capacity), scheduled class sessions bound to a studio, an instructor, and a time slot, and club-initiated session cancellation.
• Booking & Waitlist Orchestration: Booking requests within advance windows, capacity-guarded confirmation, ordered waitlist admission, time-boxed promotion offers, early and late cancellation handling, and no-show recording.
• Access Control & Attendance: Credential presentation evaluation, deterministic grant/deny decisions with explicit denial reasons, zone entitlement checks, peak-hour restrictions, day pass and guest pass validation, and check-out capture.
• Personal Training Operations: Trainer profiles and availability windows, pre-paid credit packages with validity periods, session appointment scheduling, completion sign-off, and credit refund or forfeiture on cancellation.
• Strike & Penalty Policy: Strike accrual for late cancellations and no-shows, rolling-window threshold evaluation, automatic booking privilege suspension, and strike expiry.
• Member Progress Engagement: Workout program template assignment, session completion logs, attendance streak calculation, and periodic body composition assessment records.

---

3. Out-of-Scope Boundaries

To maintain domain cohesion and prevent monolithic coupling, the Fitness context explicitly excludes generic enterprise responsibilities:

Out-of-Scope Concern	Correct Ownership	Architectural Rationale
Member master identity, contact details, marketing leads, and retention campaigns	CRM / Member Master	Fitness references member identity via a foreign identifier and local snapshot; CRM owns the member lifecycle, demographic updates, and campaign orchestration.
Recurring invoice generation, payment collection, dunning execution, refunds, and tax	Accounting / Billing (FMS)	Fitness emits billable lifecycle facts (activation, renewal, plan change, cancellation); Billing owns revenue recognition, payment retry schedules, and fiscal compliance.
SMS, email, and push notification delivery, templates, and channel retries	Notification Service	Fitness publishes notification requests with business context; the notification platform owns channel selection, delivery guarantees, and opt-out management.
Turnstile firmware, QR scanner drivers, biometric device SDKs, and hardware health monitoring	Access Hardware Vendor	Fitness evaluates access attempts and returns grant/deny decisions; vendor systems own device protocols, firmware updates, and offline hardware caching.
Trainer employment contracts, payroll calculation, and shift labor law compliance	Human Capital Management (HCM)	Fitness publishes trainer session completion facts; HCM owns contracts, compensation, and statutory labor compliance.
On-demand video workouts, wearable device telemetry, and third-party fitness app marketplaces	External Content & Wearable Platforms	Fitness stores program assignments and progress records; streaming content and raw wearable data remain with specialized external platforms.

---

4. Context Mapping & Integration Relationships

The Fitness Bounded Context interacts with surrounding enterprise domains and external service providers through explicit DDD integration patterns:

flowchart LR
    CRM["CRM / Member Master"] -->|Customer-Supplier<br/>Upstream to Downstream| FITNESS["Fitness (GYM) Context"]
    FITNESS -->|Customer-Supplier<br/>Upstream to Downstream| FMS["Accounting / Billing"]
    FMS -->|Customer-Supplier<br/>Payment Outcomes| FITNESS
    FITNESS -->|Customer-Supplier<br/>Notification Requests| NOTIFY["Notification Service"]
    GATE["Access Hardware Vendor"] <-->|Anti-Corruption Layer<br/>Decision Protocol| FITNESS
    FITNESS -->|Customer-Supplier<br/>Utilization Facts| HCM["Human Capital Management"]

Integration Relationship Details

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
CRM / Member Master	Upstream (CRM) to Downstream (Fitness)	Customer-Supplier	Fitness consumes verified member identity, contact channels, and corporate account affiliations.
Accounting / Billing	Bidirectional	Customer-Supplier (both directions)	Fitness publishes MembershipActivated, MembershipRenewed, and MembershipCancelled facts for invoicing; Billing reports MembershipPaymentFailed outcomes that trigger suspension.
Notification Service	Upstream (Fitness) to Downstream (Notifications)	Customer-Supplier	Fitness publishes time-sensitive notification requests: booking confirmations, waitlist promotion offers, freeze expiry warnings, and class reminders.
Access Hardware Vendor	Bidirectional	Anti-Corruption Layer (ACL)	Translates raw credential scans into domain access attempts and returns deterministic grant/deny decisions with display-friendly denial reasons.
Human Capital Management	Upstream (Fitness) to Downstream (HCM)	Customer-Supplier	Fitness publishes PtSessionCompleted facts for trainer utilization tracking and payroll input.

---

5. Anti-Corruption Layer (ACL) Specifications

To safeguard the Fitness domain model against foreign schemas and vendor protocols, explicit Anti-Corruption Layers translate external inputs:

1. Member Master Identity ACL

The Fitness context must never bind its membership aggregates to volatile CRM schemas. The Member Identity ACL maps external CRM member records into a localized MemberSnapshot:

• Extracts: ExternalMemberId, LegalName, DateOfBirth, PrimaryContactChannel, CorporateAccountAffiliation.
• Enforces fitness domain invariants: validates minimum age requirements for adult-only zones and computes eligibility for age-restricted plan categories (junior, student, senior).

2. Payment Gateway & Billing ACL

Recurring card charges, direct debit mandates, and refund settlements originate from external payment infrastructure. The Billing ACL insulates the membership lifecycle:

• Maps gateway-specific transaction results into domain-friendly PaymentOutcome value objects (Succeeded, FailedInsufficientFunds, FailedCardExpired, ChargebackReceived).
• Translates billing cycle invoices into abstract BillingPeriodSettlement references, keeping invoice numbering and tax jurisdictions outside the domain.
• Converts payment failure signals into the domain’s suspension trigger without leaking gateway retry logic into membership rules.

3. Access Hardware Decision ACL

Turnstiles, QR scanners, RFID readers, and biometric terminals speak vendor-specific protocols. The Access Hardware ACL protects the access decision engine:

• Maps heterogeneous credential payloads (QR token strings, RFID card UIDs, biometric template hashes) into a unified CredentialPresentation value object.
• Returns a standardized AccessDecision (Granted or Denied with a reason code such as MembershipExpired, MembershipFrozen, ZoneNotEntitled, PeakHoursRestricted) that hardware can render on entry displays.
• Supports offline hardware caching by exporting compact, signed access eligibility snapshots per member, refreshed on every state change.