# Exercise 1: Draw the Boundary — Northwind Bookings

## Scenario

Northwind is a mid-size hotel booking platform running one Node.js monolith, `northwind-api`, with one Postgres database. There are no module boundaries today — any file can `import` any other file, and over two years this has happened extensively:

- `booking/createBooking.ts` directly imports `pricing/internal/discountEngine.ts` (a file the pricing team considers a private implementation detail that changes weekly).
- `pricing/calculateRate.ts` directly queries the `bookings` table with a raw SQL string, bypassing the `booking` module's own repository layer, because it needed a rate history join and "just querying it" was faster than asking the booking team for an API.
- `notifications/sendConfirmation.ts` imports a type from `booking/internal/BookingEntity.ts` (the ORM entity, including internal fields like `internalRiskScore` that were never meant to leave the booking module).
- Three different modules (`booking`, `pricing`, `loyalty`) each independently recompute a customer's "tier" using slightly different logic copy-pasted between them.

Two teams now exist: **Stays** (booking + pricing) and **Growth** (loyalty + notifications). Both teams have been burned in the last quarter by a change in one module silently breaking another.

## Your Task

Produce a modular-monolith boundary plan for Northwind.

### Deliverables

1. **Module list and public APIs.** Propose the module boundaries (you may keep `booking`, `pricing`, `loyalty`, `notifications` or reorganize them) and, for each, list 2-4 functions/types that should make up its public surface — the only things other modules are allowed to import.
2. **Fix each violation.** For each of the four bullet points above, state exactly what changes: which internal file becomes off-limits, and what public API call replaces the direct reach-in. Be specific about the shape of the new public function (name, inputs, outputs) — not just "add an API."
3. **Enforcement mechanism.** Northwind is a TypeScript/Node codebase (no Go-style compiler-level `internal/`). Pick one enforcement mechanism from the theory's Section 3 that applies to this stack, and describe concretely how it would have caught the `pricing/calculateRate.ts` raw-SQL violation before merge.
4. **The tier-calculation duplication.** This isn't a boundary violation in the same sense — no module reached into another's internals. Explain, using the theory's model of what a public API is for, why three independent copies of the same business logic is still a modularity failure, and name which single module should own "customer tier" as part of its public API.

There is no single correct module list — grade your answer against whether every public API you propose is narrow (few functions, no leaked internal types) and whether your enforcement mechanism choice is one that actually fits a TypeScript/Node codebase.