Bounded context'e göre NestJS modülleri — 60 modülden çıkan dersler

Consulting OS'in ilk sürümü “özellik klasörü” düzenini kullanıyordu: users, projects, invoices, reports. Her özellik için bir klasör, NestJS modülü, controller, service. Klasik. Sorun 15. modül civarında başladı: yeni bir özelliğin nereye ait olduğunu kimse bilmiyordu — çünkü modüller birbirini tanıyordu ve her yeni özellik bunların 4'üne dokunuyordu.

Dönüşüm: bounded context'ler

DDD tarzı bounded context yaklaşımına geçtik. Her modül, şu kurallara sahip bir iş sınırıdır: (1) kendi alan modelinin sahibidir, (2) diğer context'lerle yalnızca event'ler üzerinden konuşur, (3) başka bir context'ten asla service import etmez, (4) veritabanı tabloları yalnızca kendisinindir — başka hiçbir modül onlara dokunmaz.

7 üst düzey kategorimiz

• 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

Ne kazandık, ne kaybettik

Kazançlar: PR'ların %80'i tek bir modüle dokunuyor, merge çakışmaları %60 azaldı. Yeni mühendisler ilk verimli commit'lerine 2 günde ulaşıyor (eskiden 4-5 gündü). Kayıplar: context'ler arasında join yapmadığımız için bazı sorgular yavaşladı — bunun yerine event'lere ve projeksiyon tablolarına dayanıyoruz. Bu, altyapıda yaklaşık %15 ek maliyet demek ve buna değiyor.

Bu kalıp 2-3 kişilik ekipler için fazla. 5 kişinin üzerinde ise zorunlu. Nortinia'daki her yeni NestJS projesi bounded context'lerle başlar — başlangıçta yalnızca 5-6 modül olsa bile. İlk 3 ay “fazla yapı” gibi görünür; 6. ayda ekip minnettar olur.