< Prev | Up: Session Overview | Next >

Session 2 — Domain & Product Model

Goal: Confirm the domain model, entity relationships, user journeys, and commercial logic are complete and correct. Estimated time: 90 min (domain-model.md alone is 43 KB — the heaviest single doc) Review status: 🟢 Reviewed — validation follow-ups tracked. Structural findings are completed; remaining unknowns are intentionally tied to customer demos and the Satzart/Kuschick implementation.

Reading Order

#	File	Lines	What It Covers
1	domain-model.md	—	Hub: bounded context map + integration surface. Entity dictionaries in spoke files under domain/.
2	PRODUCT_user-journeys.md	~100	B2C booking, dispatcher, driver, passenger flows.
3	PRODUCT_payments-and-billing.md	~80	Payment providers, billing model, subscription tiers.
4	PRODUCT_mollie-integration.md	251	Mollie API integration, deposit config, refund flows.
5	PRODUCT_migration-and-onboarding.md	~30	Concierge onboarding, legacy data migration.
6	PRODUCT_differentiators-10-percent.md	~80	Key differentiating features and competitive moats.

🔍 What to Validate

• [x] domain-model.md is the single most important file. Cross-reference key entities against the schema files (Session 5) — do they match? (Verified during Hub-and-Spoke migration)
• [x] User journeys: treat the current journeys as demo/discovery hypotheses until customer contact validates the real operator workflows. During demos, listen for role language, workarounds, ordering, exceptions, and pain points; then update the journeys against apps/workspace/docs/. (Validated 2026-05-28 as intentionally open: no customer contact yet, so completion depends on future demos/discovery calls.)
• [x] Mollie integration: the B2C deposit/balance flow remains the working hypothesis, but implementation must re-open the payment/legal surface. Track unresolved legal and product decisions explicitly, especially B2B invoice bookings, marketplace regulatory status, deposit/final-payment timing, and multi-country tours where cross-border travel law may apply. (Validated 2026-05-28: Product docs now surface B2B invoice bookings, cross-border legal review, and implementation-time validation gates.)
• [x] Are PricingRule and CapacityRule value objects defined anywhere beyond a mention? (Flagged in TODOS.md as undefined.) (Resolved: Explicitly defined in domain-backoffice.md)
• [x] payments-and-billing.md: subscription tiers intentionally remain open. Current pricing hypothesis: three tiers, with pricing based on seats/users and/or active buses. Validate the tier boundaries separately before turning this into a fixed pricing spec. (Validated 2026-05-28: Docs now separate fixed gating mechanism from configurable tier catalog and billing metrics.)
• [x] differentiators.md: are the claimed differentiators still unique, or have competitors closed the gap? (Validated 2026-05-28 as documentation hygiene: added evidence standards, confidence map, customer-validation notes, and competitor re-check TODOs. Full competitor freshness check remains a separate research task.)

🗺️ Mindmap & Path Optimization

Grab your pen and paper:

• [x] Trace the Domain Dependency Tree: Pick a Booking and trace all the entities it depends on (e.g., TourTemplate, Customer, ServiceLeg).
  • Observation: Does the document make it easy to understand these relationships, or do you have to scroll up and down constantly?
  • Optimization: Should the massive 221-line domain-model.md be split into 4 files (one for each bounded context)? (Resolved: Migrated to Hub-and-Spoke model in docs/2-areas/domain/)
• [x] Map the Data Lifecycle: How does an offline Kuschick operator migrate data (migration-and-onboarding.md) into the domain model? (Validated 2026-05-28 as intentionally open: concrete mapping rules depend on Satzart/Kuschick implementation facts and future legacy data samples.)
  • Observation: The migration doc is only 30 lines.
  • Optimization: Is the path from "legacy Excel sheet" or "Kuschick booking form submit" to "Busflow schema" clear? Where should the concrete mapping rules live?

📝 Findings & Actions

Severity	File / Topic	Issue & Optimization Potential	Action Required
🟢 Done (structural) — legal pending	Booking / Payment Legal Boundary	DEPOSIT_PAID is currently overloaded: it records a payment fact and also triggers BookingConfirmed, CostingSheet lock, confirmation messaging, FinancialLedger creation, and conditional ticket issuance. Meanwhile PRODUCT_payments-and-billing.md still marks deposit, cancellation, ticketing, payment timing, and checkout legal review as pre-launch blockers. This makes a legally/client-dependent Phase 1 assumption look like a stable domain boundary.	✅ Structural decoupling completed: Added § Scope & Legal Contingency to ADR-009 enumerating which fan-out effects the trigger does and does not legally defend (cost-lock = defended by § 651a BGB; messaging, ticketing, and deposit-collection timing = contingent on open items). Decoupled BookingConfirmed (event) from DEPOSIT_PAID (state) in domain-commerce.md § Booking, domain-backoffice.md § CostingSheet, and event-contracts-commerce.md — each downstream consumer is now modeled as an independent concern so the firing condition can be re-bound (e.g., to a "confirmed but withdrawable" sub-state) without rewriting the state machine. ⚠️ Still pending (carried in PRODUCT_payments-and-billing.md §4): lawyer confirmation of Widerrufsrecht (§ 312g BGB) applicability, § 651t Reisepreisabsicherung timing, and Mollie marketplace PSD2/ZAG status. These remain pre-launch blockers and may force re-binding the event triggers above. Supporting docs: booking-payment-legal-validation.md and dach-travel-law-payment-compliance-spec.md. Review ADR-014, booking-lifecycle-protocol.md, and cancellation-protocol.md together when legal returns.
🟢 Done	Domain Model Structure	The monolithic 43KB PRODUCT_domain-model.md was hard to navigate and trace dependencies across.	✅ Completed: Restructured into a Hub-and-Spoke architecture (docs/2-areas/domain/). Hub contains the Context Map, and 5 separate spoke files contain the entity dictionaries and aggregate definitions.
🟢 Done	Value Objects & Aggregates	PricingRule and CapacityRule were flagged as undefined. Strict transactional boundaries were unclear.	✅ Completed: Formalized PricingRule, CapacityRule, and other JSONB VOs in domain-backoffice.md. Added explicit ## Aggregates sections to all domain spokes outlining roots, children, invariants, and FK policies.
🟢 Done	Reseller Terminology	CORPORATE was too narrow for B2B buyers such as schools, clubs, public bodies, and organized groups.	✅ Completed: Renamed the documented reseller_type from CORPORATE to INSTITUTIONAL in the domain and schema docs.
🟢 Done	AncillaryCatalogItem Types	The original list (INSURANCE, UPGRADE, EXTRA_LUGGAGE, EXCURSION, MEAL, OTHER) felt arbitrary and blurred room pricing with add-ons.	✅ Completed: Reframed types as behavior-driven categories: INSURANCE, SEAT_UPGRADE, LUGGAGE, EXCURSION, MEAL, OTHER. Documented that room categories and single-room supplements belong in PriceMatrix / PricingConfig, not ancillaries.
🟢 Done	n8n Importance	n8n appeared as a central planned platform layer, although the intent is only optional early validation.	✅ Completed: Reframed n8n as a time-boxed prototype adapter. Production planning now defaults to NestJS/BullMQ/Communications services; deep protocol docs received migration warnings where they still contain historical n8n flow details.
🟢 Done	Checkout Identity Boundary	The Session 2 docs documented booker_profile_id as billing authority in domain/schema docs, but the submitCheckout protocol did not make the distinction obvious at the implementation point where DRAFT becomes PENDING_PAYMENT. That left the Phase 1 shortcut ("form submitter = primary contact passenger") too easy to misread as a domain invariant.	✅ Completed: Updated booking-lifecycle-protocol.md §submitCheckout to require booker_profile_id resolution before leaving DRAFT, name it as the post-DRAFT billing-authority invariant, and label the primary-contact resolution as a temporary Phase 1 checkout adapter shortcut.
🟡 Medium — customer validation pending	PRODUCT_user-journeys.md	6 placeholder user journeys (9–14) contain only scenario stubs — no full step-by-step narratives. Covers: Concierge Onboarding, Email-as-API Ingestion, Omnichannel Inbox Triage, Collaborative Trip Planning, Legacy Migration, Lifecycle Messaging. This is intentionally not forced to completion before real operator demos, because the current journeys remain hypotheses without customer contact.	Use demos/discovery calls to validate the journey hypotheses. Listen for actual role language, workarounds, ordering, exceptions, and pain points; then flesh out or rewrite the journeys against apps/workspace/docs/. Tracked in TODOS.md §3 (formerly SB-21).
🟡 Medium — implementation/legal review pending	PRODUCT_mollie-integration.md / PRODUCT_payments-and-billing.md	Payments are among the better documented areas, but they still contain several intentionally open questions that should be re-opened during implementation rather than treated as settled architecture. Key open surfaces: B2B invoice bookings, marketplace regulatory status, deposit/final-payment timing, cancellation/refund rules, and cross-border multi-day tours where the applicable consumer/travel-law regime may differ by country.	Keep the B2C Mollie deposit/final-payment flow as the working hypothesis, but treat implementation as the next validation gate. Before launch, legal review must explicitly cover multi-country tours and applicable-law boundaries, not only German default assumptions.
🟡 Medium — lock trigger variants pending	domain-backoffice.md § CostingSheet / ADR-009	CostingSheet currently locks as a consumer of BookingConfirmed. This remains valid, but later implementation must re-check whether Charter, manual booking, B2B invoice bookings, or a legally required "confirmed but withdrawable" state need distinct trigger handling.	Keep the current BookingConfirmed consumer model, but review trigger variants during booking/payment implementation before treating DEPOSIT_PAID or any single booking state as universally sufficient.
🟡 Medium — pricing decision pending	PRODUCT_payments-and-billing.md	The billing architecture is documented (Lago + Stripe for SaaS billing; Mollie for operator-passenger payments), but the actual subscription tiers remain intentionally open. Current commercial hypothesis: three tiers priced by seats/users and/or active buses.	Keep tier names, exact prices, and included limits out of the fixed spec for now. Revisit as a dedicated pricing decision once customer discovery and packaging assumptions are clearer.
🟡 Medium — integration design pending	PRODUCT_migration-and-onboarding.md / Satzart Kuschick integration	Migration is not only offline ETL. The Satzart/Kuschick work creates a new learning path: a booking integration service that accepts external booking-form submits, normalizes them, and writes to Kuschick now or Busflow later. The generic service should not pretend legacy specifics disappear; Kuschick likely needs a dedicated connector/sidecar with its own SOAP, auth, field mapping, status, retry, and data-construct rules.	Treat this as a concrete TODO: extract a Busflow-ready integration pattern from the Satzart service. Capture which parts are generic Booking Intake and which parts are Kuschick-specific connector logic, then promote the result into a dedicated integration spec when enough implementation facts exist.

---

< Prev | Up: Session Overview | Next >