NestJS modulok bounded context szerint — 60 modul tanulságai

A Consulting OS első verziója "feature folder" elrendezést használt: users, projects, invoices, reports. Minden feature-re egy mappa, NestJS modul, controller, service. Klasszikus. A gond ott kezdődött, amikor a 15. modulnál már senki sem tudta, hogy egy új funkció melyik mappába tartozik — mert a modulok keresztben ismertek, és az új feature egyszerre érintett 4-et.

A váltás: bounded context

Áttértünk a DDD-ből ismert bounded context megközelítésre. Minden modul egy üzleti határt képvisel, ami a következő szabályokat követi: (1) saját domain modellel rendelkezik, (2) csak eseményeken keresztül kommunikál más contextekkel, (3) sosem importál szolgáltatást másik contextből, (4) a saját adattáblája(i) csak az övé — más modul nem piszkál bele.

A 7 top-level kategóriánk

• identity/ — auth, users, tenants, roles
• billing/ — invoices, quotes, payments, reconciliation
• delivery/ — projects, tasks, time-tracking, milestones
• communication/ — email, notifications, slack, in-app
• insights/ — reports, dashboards, metrics, exports
• automation/ — workflows, scheduled jobs, webhooks
• platform/ — feature flags, audit log, search, backup

Mit nyertünk, mit vesztettünk

Nyertünk: a PR-ek 80%-a egyetlen modult érint, a merge conflict-ek számában 60%-os csökkenés. Az új csapattag 2 nap alatt ért le az első productive commit-ig (korábban 4-5 nap). Vesztettünk: néhány lekérdezés lassabb lett, mert nem join-olunk contextek között — helyette eventekre és projection táblákra támaszkodunk. Ez kb. +15% infra költség, és megéri.

Ez a pattern 2-3 ember alatt overkill. 5 fő fölött kötelező. A Nortinia minden új NestJS projektjét bounded context szerint indítjuk — még akkor is, ha az elején csak 5-6 modul van. Az első 3 hónapban úgy tűnik, hogy "túl sok struktúra", a 6. hónapban köszöni, hogy van.