Modular Monolith’te Domain Boundary Nasıl Tasarlanır?

Domain boundary, Modular Monolith mimarisinin en kritik parçasıdır. Çoğu sistemin başarısız olmasının sebebi yanlış teknoloji seçimi değil, yanlış boundary tanımıdır.

Gerçekte mimari kararların büyük bölümü deployment modelinden değil, domain’in nasıl bölündüğünden kaynaklanır.

Bu yazıda domain boundary’yi teorik değil, tamamen pratik ve failure-driven bir perspektifle ele alacağız.

Core Problem: Yanlış Bölünmüş Domain

Bir sistemi modüllere ayırmak kolaydır. Ancak doğru şekilde ayırmak zordur.

Çoğu ekip şu hatayı yapar:

• Teknik katmanlara göre bölme (Controller, Service, Repository)
• Database tablolarına göre bölme
• UI akışına göre bölme

Bu yaklaşımlar domain boundary üretmez — sadece kod organizasyonu üretir.

Sonuç: yüksek coupling, düşük cohesion.

Bounded Context: Gerçek Sınır Nerede Başlar?

Domain Driven Design (DDD) içinde Bounded Context, bir modelin geçerli olduğu sınırı ifade eder.

Yani:

Aynı kavram farklı context’lerde farklı anlamlara sahip olabilir.

Örnek:

• Order → satış context’inde sipariş
• Order → warehouse context’inde sevkiyat birimi

Bu iki model aynı entity değildir ve aynı modülde olmamalıdır.

En büyük hata: bu farkı görmezden gelip tek bir “Order” modeli yaratmaktır.

Boundary Belirleme Heuristics (Pratik Kurallar)

Teoride her şey net görünür. Pratikte boundary bulmak için şu soruları sormalısın:

• Bu modül kendi başına anlamlı mı?
• Bu modül olmadan diğer modüller çalışabilir mi?
• Bu modülün datası başka bir modül için kritik mi?

Eğer bir modül sürekli başka modüllere ihtiyaç duyuyorsa, boundary yanlış çizilmiş olabilir.

Aggregate Design: Boundary’nin İç Yapısı

Boundary sadece modüller arası değil, modül içindeki yapı için de geçerlidir.

DDD’de bu yapı Aggregate ile tanımlanır.

Bir aggregate:

• Consistency boundary’dir
• Transaction scope’u belirler
• Dış dünyaya tek entry point sunar

En kritik kural:

Aggregate dışından internal state’e erişim olmamalı

Bu kural ihlal edilirse, modül içi coupling artar ve boundary anlamını kaybeder.

Dependency Rule: Kim Kime Bağımlı?

Boundary tasarımında en önemli konulardan biri dependency yönüdür.

Sağlıklı bir sistemde:

• Domain → bağımsızdır
• Application → domain’i kullanır
• Infrastructure → en dış katmandır

Ancak modüller arası dependency daha kritiktir:

• Bir modül diğerinin internal yapısını bilmemeli
• Sadece contract üzerinden iletişim kurmalı

Anti-pattern:

Direct repository access (başka modülün verisine doğrudan erişim)

Bu durum boundary’yi anında yok eder.

Integration Pattern: Modüller Nasıl Konuşmalı?

Modüller arası iletişim için 3 temel yaklaşım vardır:

1. Direct Method Call

• Basit
• Düşük latency
• Yüksek coupling riski

2. Application Service üzerinden iletişim

• Kontrollü erişim
• Boundary korunur

3. Domain Events

• Loose coupling
• Event-driven yaklaşım
• Complexity artışı

Genel öneri:

Önce basit başla, sadece ihtiyaç olduğunda event-driven modele geç

En Büyük Hata: Shared Database Illusion

Modular Monolith’te en sık yapılan hata:

“Zaten aynı database, istediğim tabloya erişirim” yaklaşımı

Bu yaklaşım şu sonuçları doğurur:

• Boundary ihlali
• Hidden coupling
• Refactor kabiliyeti kaybı

Doğru yaklaşım:

• Her modül kendi datasının sahibi olmalı
• Başka modülün datasına sadece API üzerinden erişilmeli

Kırılma Noktası: Boundary Ne Zaman Çöker?

Boundary’ler genellikle şu durumlarda çöker:

• Deadline baskısı altında “shortcut” alınır
• Direct DB access başlar
• Modüller arası dependency kontrol edilmez

Bu noktadan sonra sistem Modular Monolith değildir.

Artık sadece parçalanmış bir monolith’tir.

Insight

Doğru boundary çizmeden yapılan her modülerlik çabası, sadece organize edilmiş bir kaostur.

Sonuç

Modular Monolith’in başarısı teknoloji seçiminden değil, boundary disiplininden gelir.

Eğer domain doğru bölünmemişse, Microservices de çözüm değildir.

Çünkü yanlış bölünmüş bir sistemi dağıtmak, problemi çözmez — sadece daha zor debug edilir hale getirir.