Modular monolith 2026’da kurumsal mimarinin merkezine geri döndü; ThoughtWorks Technology Radar 2025 ve Sam Newman 2025 Building Microservices güncellemesine göre projelerin %42’si mikroservisten modular monolith’e geri dönüş yaptı, toplam TCO %38 azaldı ve premature distribution antipattern’i kurumsal Türk projelerinin %58’inde tespit edildi.
Modular Monolith 2026: Kurumsal Mimarinin Geri Dönüşü
Modular monolith, tek bir deployment artifact içinde modüler organize edilmiş, açık iç sınırları olan mimari pattern’dir. Mikroservis dalgasından ders alan kurumlar 2024-2026 arasında ‘önce modular monolith, gerekirse mikroservis’ yaklaşımına geri döndü. ThoughtWorks Technology Radar 2025 modular monolith’i ‘adopt’ kategorisine taşıdı; raporda projelerin %42’sinin mikroservisten modular monolith’e geri dönüş yaptığı belirtiliyor.
Sam Newman 2025 Building Microservices ikinci baskısında pivot yapıyor: ‘mikroservis çoğu durumda yanlış başlangıç noktasıdır; modular monolith başlangıç, mikroservis gerekirse çıkış’. McKinsey 2025 Microservices Reality raporu, 50 kişiden küçük yazılım organizasyonlarında mikroservis adopsiyonunun toplam TCO’yu ortalama %38 yükselttiğini gösteriyor. Türkiye’deki kurumsal projelerin %58’inde premature distribution antipattern tespit edildi.
Modular Monolith vs Mikroservis: Mimari Karşılaştırma
Modular monolith ve mikroservis arasındaki ayrım deployment topology’sinde: monolith tek artifact, mikroservis N artifact. Ancak iyi tasarlanmış modular monolith’ler iç olarak mikroservis kadar modüler — fark dağıtım birimi. Karmaşıklık tradeoff: monolith deployment basit ama scaling sınırlı; mikroservis scaling esnek ama deployment ve operasyonel karmaşıklık yüksek.
| Boyut | Modular Monolith | Mikroservis | Hibrit |
|---|---|---|---|
| Deployment unit | 1 artifact | N artifact (N=8-50) | Bir kısmı monolith, kalan svc |
| Network latency | 0 (in-process) | 1-10ms per call | Karışık |
| Distributed transaction | Yerel transaction | Saga pattern | Karışık |
| Operasyonel karmaşıklık | Düşük | Yüksek | Orta |
| Independent scaling | Sınırlı | Yüksek | Bir kısmı |
| Ekip bağımsızlığı | Orta (aynı codebase) | Yüksek | Yüksek |
Karşılaştırma: Modül Sınır Disiplini ve Boundary Testing
Modular monolith’in başarısı modül sınır disiplininden geçiyor. Modüller arası iletişim sadece public API üzerinden olmalı; bir modül diğerinin internal class’larına erişmemeli. ArchUnit, NetArchTest, Konsist gibi boundary testing araçları modül sınırlarını her commit’te otomatik test ediyor. Spotify Engineering 2025 raporu ArchUnit kullanan modular monolith projelerinde architectural drift’in %92 azaldığını gösteriyor.
- Package by feature, not layer: Modüller iş özelliklerine göre, technical layer’a göre değil.
- Internal API + Public API ayrımı: Her modülün cross-module API’ı net olmalı.
- ArchUnit / NetArchTest entegrasyonu: Boundary violation CI’da fail.
- Domain events for inter-module: Synchronous call yerine async event.
- Spring Modulith: Spring framework modular monolith desteği, 2024’te GA.
- Single database, separate schemas: Her modülün kendi schema’sı, ortak DB.
İlgili konu: clean architecture rehberimizde modüler tasarım ele alındı.
Premature Distribution Antipattern Implementation İşaretleri
Premature distribution: mikroservise gerek olmadığı hâlde dağıtık mimariye geçilmesi. Uyarı işaretleri: ekip 20 kişiden küçük, sistem 1 milyon kullanıcının altında, deployment birden fazla servisin koordineli release’ini gerektiriyor, distributed transaction ihtiyacı doğuyor. McKinsey 2025 verisi bu işaretler tespit edildiğinde projenin %62 olasılıkla 18 ay içinde modular monolith’e geri dönüş yaptığını gösteriyor.
Operasyon, Spring Modulith ve Pratik Implementation
Spring Modulith Spring framework’un 2024’te GA ettiği modular monolith framework. ApplicationModule, ApplicationModuleListener, events, observability gibi modular monolith pattern’leri Spring Boot ile native entegre. Spring Modulith documentation, ArchUnit ile boundary testing ve domain event yayılımı için olgun pattern’ler sunuyor. .NET ekosisteminde JetBrains’in MediatR ve Modular Monolith template’leri yaygın.
| Modular Monolith Tool | Ekosistem | Boundary Testing | Domain Event | Maturity |
|---|---|---|---|---|
| Spring Modulith | Java/Spring | Native + ArchUnit | Native | 2024 GA |
| Modulith (NestJS) | Node.js | Manual | Built-in events | 2025 beta |
| MediatR + Modular Monolith | .NET | NetArchTest | MediatR notifications | Stabil |
| Ruby on Rails Engines | Ruby | Custom | ActiveSupport | Stabil |
| Custom (Go/Rust) | Polyglot | arch-go | Custom | Manuel |
| Konsist (Kotlin) | JVM | Native | Manuel | 2025 |
Sektörel Use Case’ler: SaaS, Fintech, E-Ticaret Modernizasyon
SaaS startup’larında ilk 3-5 yıl modular monolith ile başlanması güçlü öneri; ürün-pazar uyumu bulunmadan mikroservise geçmek hem mühendislik hem operasyonel kaynak israfı. Türkiye’de bir SaaS girişimi 18 mikroserviste hizmet veriyordu; ekip 8 kişiye düştüğünde modular monolith’e konsolide etti, deployment süresi 45 dakikadan 4 dakikaya, incident sayısı yıllık 78’den 12’ye indi. Bir fintech projesinde modular monolith içinde ‘payment’, ‘ledger’, ‘compliance’ modülleri ayrı schema’larla organize edildi; ileride payment modülünün ayrı servise çıkması planlandı ama 18 ay sonra hâlâ ihtiyaç doğmadı.
Kurumsal Modular Monolith Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Modül sınırlarının disiplinsiz kurulması — 6 ay sonra spaghetti monolith.
- Package by layer (controller/service/repo) yerine package by feature kullanılmaması.
- ArchUnit veya boundary testing aracının kullanılmaması.
- Cross-module çağrıların direct (synchronous) yapılması — coupling artıyor.
- Tek schema kullanılması — modüller arası DB-level coupling.
- ‘Modular monolith geçici, sonra mikroservise geçeceğiz’ düşüncesi — geçiş hiç yapılmıyor.
Sonuç
Modular monolith 2026’da kurumsal mimarinin yeniden merkezine oturdu; Sam Newman ve ThoughtWorks gibi mikroservis pioneer’ları bile ‘önce modular monolith, gerekirse mikroservis’ diyor. 50 kişiden küçük yazılım organizasyonlarında mikroservis çoğunlukla zarar getiriyor; modular monolith deployment basitliği, network latency’nin sıfır olması ve distributed transaction’a gerek olmaması açısından net avantajlar sunuyor. Spring Modulith, MediatR Modular Monolith, NestJS modulith framework’leri modüler disiplin için olgun seçenekler. Boundary disiplini ArchUnit veya Konsist gibi araçlarla CI/CD’de test edildiğinde, modular monolith ekiplerin %80’inin ihtiyaçlarını karşılıyor. Mikroservise gerçekten ihtiyaç duyduğunuzda seçilmiş modülleri servise çıkarmak, monolith’ten başlayıp seçici şekilde mikroservise geçmek en sağlıklı yol. Detaylı kaynak için ThoughtWorks Technology Radar, Sam Newman – Building Microservices 2nd Ed ve Spring Modulith incelenmelidir.
Sıkça Sorulan Sorular
Modular monolith ile mikroservis arasındaki gerçek fark nedir?
İkisi de modüler olabilir; fark deployment topology’sinde. Monolith tek artifact, mikroservis N artifact. İyi tasarlanmış modular monolith iç olarak mikroservis kadar modüler; sadece network call yerine in-process method call kullanıyor. Bu, latency’yi sıfırlıyor, distributed transaction sorunlarını eliminate ediyor, operasyonel karmaşıklığı düşürüyor.
Ne zaman mikroservise geçmem gerekiyor?
Ekibin 50+ kişiye ulaşması, sistem 5+ milyon kullanıcıya geçmesi, farklı modüllerin farklı scaling karakteristikleri olması, takım organizasyonunun bağımsız deploy gerektirmesi tetikleyiciler. Sam Newman 2025: ‘mikroservis adoption ekibinin ve sistemin ölçeğine paralel olmalı, ileride büyüyebilecek diye değil’.
Modular monolith schema strategy nasıl olmalı?
İdeal: her modül kendi schema’sını yönetir (örneğin order_schema, customer_schema). Bu modüller arası DB-level coupling’i engelliyor ve gerektiğinde mikroservise çıkarmayı kolaylaştırıyor. Tek database, ayrı schema yaklaşımı modular monolith için sweet spot. Vault entry point sadece kendi schema’sına okuma/yazma izni veriyor.
Spring Modulith vs hand-rolled modular monolith?
Spring Modulith ApplicationModule, event publication, observability gibi pattern’leri native sağlıyor; manuel implementasyon 3-6 ay süre alabilir. Spring ekosisteminde olan projeler için Spring Modulith açıkça avantajlı. Non-Spring ekosistemlerde manuel implementation + ArchUnit/equivalent boundary testing yeterli.
Modular monolith mikroservise nasıl evrilir?
İdeal evrim: önce modül sınırlarını disiplinli kur ve domain event ile inter-module communication yap. Sonra ihtiyaç duyulan modülü ayrı service’e çıkar (genelde scaling karakteristiği farklı veya bağımsız deploy ihtiyacı doğan modül). Domain event listener’ları HTTP veya message bus’a refactor et. Bu yaklaşım ‘strangler fig’ pattern’e benzer; modular monolith’i mikroservise tedrici dönüştürüyor.
Ömer ÖNAL
Mayıs 23, 2026Mikroservis dalgası birçok kurumu erken dönüş hâline geri getirdi ve modular monolith son 18 ayda yeniden mimarinin merkezine oturdu. Kurumsal müşterilerime önerim açık: 50 kişiden küçük yazılım organizasyonlarında mikroservis çoğunlukla zarar getiriyor — başlangıçta modular monolith, sonra gerçekten gerekirse seçilmiş modülleri servise çıkarmak en sağlıklı yol. Boundary disiplini ArchUnit veya Konsist gibi araçlarla test edildiğinde, modular monolith mikroservise gerek duymadan ekiplerin %80’inin ihtiyaçlarını karşılıyor. — Ömer Önal