Modular Monolith Nedir? Domain Boundary ve Evrimsel Mimari Perspektifi

Modular Monolith, genellikle Microservices’e alternatif olarak konumlandırılsa da, gerçekte daha temel bir problemi çözmeye çalışır: domain boundary’lerin doğru tanımlanması.

Çoğu sistemde problem dağıtık olup olmamak değil, domain’in yanlış bölünmesidir. Bu nedenle Modular Monolith, dağıtımı değil bağımlılık yönetimini optimize eder.

Core Problem: Coupling vs Cohesion

Bir sistemin sağlıklı olup olmadığını belirleyen en kritik iki metrik:

• Cohesion: Aynı modül içindeki bileşenlerin birlikte ne kadar anlamlı olduğu
• Coupling: Modüller arası bağımlılık seviyesi

Microservices genellikle coupling’i azaltmak için kullanılır. Ancak yanlış domain ayrımı yapıldığında, coupling sadece process boundary’nin dışına taşınır.

Yani:

In-process coupling → network coupling’e dönüşür

Bu da sistemi daha karmaşık hale getirir, daha basit değil.

Modular Monolith’in Asıl Gücü: Boundary Enforcement

Modular Monolith’in değeri, tek deploy olmasında değil, boundary’leri enforce edebilmesindedir.

İyi tasarlanmış bir sistemde:

• Her modül kendi domain modeline sahiptir
• Başka modüllerin internal state’ine erişemez
• Sadece tanımlı contract’lar üzerinden iletişim kurar

Bu noktada kritik soru:

Bu boundary’leri nasıl enforce edeceksin?

Enforcement Teknikleri

• Assembly bazlı ayrım (.NET projeleri)
• Internal visibility (internal / friend assemblies)
• Interface bazlı erişim
• Application layer üzerinden erişim zorunluluğu

Eğer bu kurallar compile-time’da enforce edilmiyorsa, zamanla ihlal edilir.

Data Ownership Problemi

Microservices’in en güçlü iddialarından biri “her servis kendi datasına sahip olmalı” yaklaşımıdır.

Modular Monolith’te ise genellikle tek bir database vardır. Ancak bu, data ownership olmadığı anlamına gelmez.

Doğru yaklaşım:

• Logical data ownership
• Schema-level separation
• Direct table access’in engellenmesi

En büyük anti-pattern:

Her modülün her tabloya erişebilmesi

Bu durum sistemin modülerliğini tamamen yok eder.

Transaction Yönetimi: Hidden Advantage

Modular Monolith’in en büyük ama en az konuşulan avantajlarından biri transaction yönetimidir.

Tek process içinde:

• ACID transaction’lar doğal olarak desteklenir
• Eventually consistency ihtiyacı azalır
• Saga pattern gibi karmaşık çözümler gerekmez

Microservices’te ise:

• Distributed transaction zordur
• Eventual consistency zorunlu hale gelir
• Data consistency trade-off’a dönüşür

Communication Model: In-Process vs Network

Modular Monolith:

• Method call → düşük latency
• Strong typing → compile-time safety

Microservices:

• HTTP / messaging → yüksek latency
• Serialization/deserialization maliyeti
• Network failure riskleri

Buradaki kritik fark şudur:

Network her zaman en zayıf halkadır

Evrimsel Mimari: Ne Zaman Parçalamalısın?

En doğru yaklaşım genellikle sistemin baştan Microservices olarak tasarlanmaması, zamanla evrilmesidir.

Parçalama için sinyaller:

• Bağımsız scaling ihtiyacı
• Takım bazlı ownership gereksinimi
• Deployment bottleneck’leri

Bu sinyaller yoksa, Microservices erken bir optimizasyondur.

Insight

Yanlış bölünmüş bir sistemi Microservices yapmak, problemi çözmez. Sadece problemi dağıtır.

Sonuç

Modular Monolith, basit bir mimari tercih değil, sistemin doğru evrimleşmesini sağlayan bir stratejidir.

Asıl mesele monolith vs microservices değil, boundary’lerin ne kadar doğru tanımlandığıdır.