Modular Monolith’te Data Ownership ve Database Tasarımı Nasıl Olmalı?

Data ownership, Modular Monolith mimarisinin en kritik ama en çok ihmal edilen konusudur. Çoğu sistemin “modüler” başlayıp zamanla klasik monolith’e dönüşmesinin sebebi yanlış database kullanımıdır.

Çünkü gerçek şu: boundary’ler kodda değil, datada kırılır.

Bu yazıda Modular Monolith içinde data ownership nasıl tasarlanmalı, hangi hatalar sistemi geri dönülmez hale getirir ve doğru yaklaşım nedir, bunları teknik olarak ele alacağız.

Core Problem: Shared Database Yanılgısı

Modular Monolith’te genellikle tek bir database kullanılır. Bu durum çoğu geliştiricide şu yanlış algıyı oluşturur:

“Aynı database ise istediğim tabloya erişebilirim.”

Bu düşünce, modülerliği en hızlı yok eden anti-pattern’dir.

• Her modül her tabloya erişmeye başlar
• Bağımlılıklar görünmez hale gelir (hidden coupling)
• Refactor etmek neredeyse imkansız hale gelir

Sonuç: sistem teknik olarak modüler görünür, ama davranış olarak tamamen monolith’tir.

Data Ownership Nedir?

Data ownership, her modülün kendi verisinin tek sahibi olması anlamına gelir.

Yani:

• Bir modül kendi datasını yönetir
• Başka modüller bu dataya doğrudan erişemez
• Erişim sadece tanımlı API/contract üzerinden yapılır

Bu kural ihlal edildiği anda boundary anlamını kaybeder.

Physical vs Logical Separation

Microservices dünyasında data ownership genellikle fiziksel olarak çözülür (ayrı database).

Modular Monolith’te ise bu ayrım genellikle logical seviyededir.

Physical Separation

• Ayrı database
• Güçlü izolasyon
• Operasyonel maliyet yüksek

Logical Separation

• Aynı database
• Schema veya naming ile ayrım
• Disiplin gerektirir

Modular Monolith’te doğru yaklaşım çoğu zaman logical separation’dır.

Ancak kritik nokta:

Logical separation, kuralla enforce edilmezse yoktur.

Schema Isolation: Minimum Gereksinim

En basit ve etkili tekniklerden biri schema bazlı ayrımdır.

• order schema
• inventory schema
• billing schema

Bu yaklaşım:

• Data ownership’i görünür hale getirir
• Yanlış erişimleri azaltır
• Boundary farkındalığını artırır

Ancak tek başına yeterli değildir.

Gerçek Problem: Direct Table Access

En tehlikeli anti-pattern:

Bir modülün başka bir modülün tablosuna doğrudan erişmesi

Örnek:

• Order modülü → Inventory tablosuna query atıyor

Bu durum şu problemlere yol açar:

• Hidden coupling
• Değişikliklerin zincirleme etkisi
• Refactor maliyetinin artması

Bu noktadan sonra modüller bağımsız değildir.

Doğru Yaklaşım: API Üzerinden Data Erişimi

Bir modül başka bir modülün datasına ihtiyaç duyuyorsa:

Doğrudan DB yerine, o modülün application service’i üzerinden erişmelidir.

Bu yaklaşım:

• Boundary’yi korur
• Değişiklikleri izole eder
• Gelecekte Microservices’e geçişi kolaylaştırır

Read Model Problemi

En zor konulardan biri şudur:

“Ben sadece okumak istiyorum, yine de API mi kullanmalıyım?”

Kısa cevap: evet.

Uzun cevap:

• Read access bile coupling oluşturur
• Schema değişiklikleri kırılmaya sebep olur

Alternatif yaklaşım:

• Read model oluşturmak
• Projection kullanmak
• Cache layer ile çözmek

Bu noktada CQRS yaklaşımı devreye girebilir.

Transaction Boundary: Gizli Tuzak

Modular Monolith’in avantajlarından biri transaction kolaylığıdır.

Ancak yanlış data erişimi bu avantajı bozar.

Örnek problem:

• Birden fazla modül aynı transaction içinde update ediliyor

Bu durum:

• Modül bağımsızlığını bozar
• Gelecekte parçalamayı zorlaştırır

Doğru yaklaşım:

Her modül kendi transaction boundary’sine sahip olmalı

Kırılma Noktası: Sistem Ne Zaman Geri Dönülemez Hale Gelir?

Şu noktada sistem artık kurtarılamaz hale gelir:

• Her modül her tabloya erişiyorsa
• Data ownership yoksa
• Transaction boundary’ler karışmışsa

Bu noktadan sonra:

Microservices’e geçiş bile problemi çözmez

Çünkü problem mimari değil, veri modelidir.

Insight

Code bağımlılıklarını refactor edebilirsin. Ama data bağımlılıkları kalıcıdır.

Sonuç

Modular Monolith’te başarının anahtarı kod organizasyonu değil, data disiplinidir.

Eğer data ownership doğru kurulmamışsa, sistem ne kadar modüler görünürse görünsün, gerçekte tek parça bir monolith’tir.

Ve bu noktadan sonra sistemi düzeltmek, sıfırdan yazmaktan daha zor hale gelir.