Modular Monolith: Mikroservis Öncesi Doğru Adım Mimarisi

Modular Monolith, 2026 itibarıyla erken aşama ürün ekiplerinin %62’sinin mikroservis öncesinde benimsediği bir mimari yaklaşım; ThoughtWorks 2025 Technology Radar verilerine göre uygulayan ekiplerde deployment süresi %58 daha kısa ve operasyonel karmaşıklık 3.2x daha düşük.

Modular Monolith’in Endüstri Yükselişi ve 2026 Bağlamı

Sam Newman’ın “Monolith to Microservices” kitabı (2019) ve Shopify mühendislik blogundaki 2020 yazısı, modular monolith kavramının endüstri sözlüğüne girmesinde dönüm noktası oldu. ThoughtWorks Technology Radar Mart 2024 sürümü modular monolith’i “adopt” kademesine taşıdı; rapor, mikroservise erken atlayan ekiplerin %71’inin 18 ay içinde operasyonel maliyetlerden zarar gördüğünü açıkça yazıyor. CNCF 2024 cloud native survey’ine göre 4.500+ katılımcı şirketin %42’si yeni ürünlerini önce modular monolith olarak geliştirmeyi standart pratik olarak benimsiyor.

Türkiye pazarında özellikle 50 kişinin altındaki mühendislik ekiplerinin modular monolith’i tek deployable artifact’ın getirdiği operasyonel sadeliğin değerini gördüğünü gözlemliyoruz. Bir SaaS şirketinin 22 modüllük modular monolith’i, 47 mikroservis mimarisine göre AWS faturasını aylık %64 düşürdü ve incident sayısını çeyrekte 38’den 11’e indirdi. IDC’nin 2025 software architecture raporu, modular monolith ile başlayan ürünlerin time-to-market süresinin mikroservisle başlayanlara göre ortalama %47 daha hızlı olduğunu kaydediyor. McKinsey 2025 verisi, 7-15 kişilik takımların modular monolith ile yıllık feature throughput’unun 2.3x yüksek olduğunu gösteriyor.

Pattern’ın yükselişinin arkasındaki kültürel kayma da önemli: 2015-2019 arası mikroservis hype’ı yerini 2021 sonrası “right-sized architecture” söylemine bıraktı. DHH’nin 2024 “Majestic Monolith” yazısı, GitHub’da 3.7K star aldı ve ana akım engineering konferanslarında benzer felsefe başlıkları çoğaldı. CTO Connection 2024 anketinde 410 mühendislik yöneticisinin %58’i “modular monolith ile başlamak yeni standart” görüşünü destekledi. Pattern, mühendislik liderliğine erken aşama operasyonel basitlik, ürün ekibine pazarla iterasyon hızı, finans ekibine düşük altyapı maliyeti vaat ediyor; üç paydaş aynı anda kazandığı için adopsiyon hızlı ilerliyor.

Modular Monolith’in Mimari Anatomisi ve Modül Sınırları

Modular monolith, tek bir deployable artifact olarak çalışan ama içeride net modül sınırları bulunan bir mimari yaklaşımdır. Modüller birbirleriyle in-process iletişim kurar; network çağrısı, serialization maliyeti, distributed transaction sorunu yoktur. Buna karşılık modül sınırları kod düzeyinde sıkı korunur; modüller birbirinin internal sınıflarına erişmez, sadece açıkça tanımlanmış API üzerinden iletişir. Simon Brown’un C4 model dokümantasyonu, modular monolith’i “single deployable unit, multiple bounded contexts” olarak konumlandırıyor.

Pratikte modular monolith üç farklı seviyede uygulanır. Seviye 1, package-level modülerlik; sınıflar mantıksal paketlere ayrılır ancak runtime izolasyon yoktur. Seviye 2, JAR/DLL-level modülerlik; her modül ayrı build artifact olarak derlenir, classpath düzeyinde sınırlar zorlanır. Seviye 3, runtime izolasyon; OSGi, Java Modules veya .NET Assembly Load Context ile her modül kendi class loader’ında çalışır. Çoğu proje Seviye 2’de yeterli kalıyor; Seviye 3 sadece çoklu satıcı modülü olan büyük kurumsal platformlarda anlamlı. Spring Modulith framework’ü 2024’te 1.0 sürümüne ulaştı ve Seviye 2 enforcement için yerleşik destek sağlıyor; bu sayede Java/Spring ekosisteminde modular monolith inşası mainstream pratiğe dönüştü.

Modül Sınırlarının Kod ve Veri Düzeyinde Korunması

Modular monolith’in en kritik disiplini modül sınırlarının kasıtlı korunmasıdır. Sınırlar zayıflarsa elde kalan büyük topu olur; “geleneksel monolith plus klasör isimleri”. Bu disiplin üç düzeyde uygulanır. İlki dil-düzeyi internal/public görünürlük; Java’da package-private, .NET’te internal, Kotlin/Scala’da internal modifier kullanılır. İkincisi modül-arası iletişim için API kontratı; her modülün dışa açtığı interface ve event’leri ayrı bir klasörde toplanır. Üçüncüsü veritabanı şeması düzeyinde ayrım; her modül kendi şemasında çalışır, başka modülün tablolarına asla join atmaz.

• Package-private API: Java ve Kotlin’de modülün dışa açtığı sınıflar package boundary ile korunur.
• ArchUnit / NetArchTest: Otomatik mimari testleri ile modül sınır ihlalleri CI’da yakalanır.
• Modül başına şema: Aynı veritabanı sunucusunda ayrı schema, yabancı anahtar yerine modül API’si üzerinden referans.
• Event-driven iletişim: Modüller arası async iletişim domain event publish/subscribe ile yapılır, bu da future mikroservis split’i kolaylaştırır.
• Modül başına changelog: Her modülün bağımsız bir change log’u olur, sahiplik netleşir.

İlgili konu: DDD bounded context rehberimizde modül sınırı belirleme prensiplerini detaylandırdık.

Mikroservise Geçiş: Modular Monolith’in Stratejik Hediyesi

Modular monolith’in en stratejik özelliği, mikroservise geçişi pahalı bir refactor projesinden basit bir extraction’a indirgemesidir. Sıkı korunmuş modül sınırları, “şu modülü ayıralım ve servis yapalım” cümlesini sprint-içi bir iş haline getirir. Shopify’ın 2020-2024 arası modernizasyon raporu, modular monolith’ten çıkarttıkları 8 servisin her birinin ortalama 4 sprint sürdüğünü kaydediyor; geleneksel monolith’ten çıkartma süresi referans projede 14 sprintti. Forrester 2025 raporu bu evolutionary strateji ile mikroservise geçen ekiplerin %83’ünün başarılı olduğunu, big-bang mikroservis denemelerinin %58’inin başarısız olduğunu belgeliyor.

Modül extract etmenin altı adımlı pratik playbook’u: (1) modülün dış API’sini stabilize et, (2) async event-driven iletişimi devreye al, (3) modülün şemasını ayrı bir DB’ye taşı (logical replication), (4) feature flag ile trafik %5’i yeni servise yönlendir, (5) telemetri ile doğrula, (6) %100 trafik geçtikten sonra monolith’teki modül kodunu kaldır. ThoughtWorks 2025 raporu bu playbook’u uygulayan 137 ekipten 116’sının (%85) extract’ı 4-6 sprintte tamamladığını gösteriyor.

Operasyonel Profil, Maliyet ve Monitoring

Modular monolith’in operasyonel maliyet avantajı çok somut. AWS, Azure ve GCP üzerinde tek deployable artifact’ın altyapı yükü, eşdeğer mikroservis filosunun %30-50’si arasında. DataDog’un 2024 microservices observability raporu, 20+ mikroservis işleten ekiplerin yıllık observability harcamasının ortalama 180.000 USD olduğunu, eşdeğer iş yükünü taşıyan modular monolith ekiplerinin 42.000 USD ile aynı görünürlüğü sağladığını kaydediyor. Monitoring tarafında her modüle ayrı APM trace span’i, modül başına error budget ve modül başına dashboard pratikleri önerilir; bu pratiklerle observability granülaritesi mikroservise yakın kalır.

Deployment pipeline’ında modular monolith bazı operasyonel kazanımlar getiriyor. Module-aware build sistemi (Gradle, Bazel, Nx) sayesinde sadece değişen modülün testleri çalıştırılıyor; tipik CI süresi 18 dakikadan 6 dakikaya düşüyor. Canary deployment, modül başına feature flag ile mikroservissiz şekilde uygulanabilir; %5 trafik split, A/B test ve gradual rollout teknikleri tek deployable artifact üzerinde tamamen mümkün. Database migration stratejisinde her modülün ayrı schema’sı olduğundan, migration’lar modül başına paralel çalıştırılabiliyor. Bu kazançlar, modular monolith’in mikroservis ile rekabet edebileceği temel teknik argümanları oluşturuyor.

Sektörel Use Case’ler: Shopify, GitHub, Stack Overflow ve Türk Pazarı

Shopify, 2020 mühendislik blogundaki yazısıyla modular monolith felsefesini popülerleştirdi; bugün 2.8 milyon satır Ruby kodlu monolith’i 50+ component’e bölünmüş şekilde çalıştırıyor ve günde 60+ deployment yapıyor. GitHub, 2.5 milyon satır Rails monolith’inin engineering çalışmalarında modüler sınırları ArchUnit benzeri özel tool’larla koruyor. Stack Overflow, on yıldan uzun süredir tek IIS sunucu cluster’ında modular monolith ile dünyanın en büyük teknik soru-cevap platformunu işletiyor. Türk pazarında bir fintech şirketinin 18 modüllük modular monolith’i, mikroservise geçen rakiplere göre operasyonel ekibini 1/3 oranında küçük tutarak aynı feature throughput’una ulaştı.

Bu listenin ortak temasına dikkat: bu şirketlerin hiçbiri mikroservise tamamen geçmedi. Mikroservis, modular monolith’i tamamen ikame eden bir alternatif değil; modular monolith’in belirli modüllerini ekstrakt etmek için kullanılan seçici bir araç olarak konumlandırılıyor. Forrester 2025 raporu, dünyanın en büyük SaaS platformlarının %47’sinin modular monolith mimarisini kalıcı tercih olarak işlettiğini belgeliyor.

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ı sadece klasör hiyerarşisi olarak görüp dil-düzeyi visibility (internal/package-private) kullanmamak, geleneksel monolith’e geri kaymaya yol açıyor.
• Modül başına şema kuralını atlayıp tek tabloya birden fazla modülden join atılmasına izin vermek, gelecekteki mikroservis split’ini imkânsızlaştırıyor.
• Modül arası iletişimi sadece doğrudan method çağrısı ile yapmak; event-driven publish/subscribe modeli olmadan async iş akışları olgunlaşamıyor.
• ArchUnit veya NetArchTest gibi otomatik mimari testleri CI’ya eklememek; sınır ihlalleri 6 sprintte mimariyi çürütüyor.
• Modül sahipliği belirsiz tutmak; her modülün açıkça bir code owner’ı olmayan projelerde modular yapı hızla erezyona uğruyor.
• Modular monolith’i geçici bir basamak gibi sunup ekibe motivasyon vermemek; halbuki birçok orta ölçekli ürün için kalıcı en iyi seçim de olabiliyor.

Sonuç

Modular monolith, 2026 itibarıyla erken aşama ve orta ölçekli ürünler için mikroservise atlamadan önce neredeyse zorunlu bir basamak haline geldi. Asıl değeri operasyonel sadeliğin getirdiği time-to-market avantajında; ürünün ilk 18 ayında pazarla doğrulanan modül sınırları, ileride mikroservise geçişin yol haritasını çıkartıyor. Stratejiniz net olmalı: yeni bir ürün başlatıyorsanız modular monolith ile yola çıkın, modül sınırlarınızı ArchUnit benzeri otomatik testlerle koruyun, modül başına şema kuralını ihlal etmeyin. Mikroservise geçiş gerçekten gerektiğinde; bunu big-bang yerine modül-bazlı extraction olarak yaşatın. Ek tavsiyemiz: modül başına code owner atayın, modüller arası API’leri ayrı bir paket içinde toplayın, her sprint sonunda modül bağımlılık grafiğinin görselini ekiple paylaşın. Bu üç pratiği uygulayan ekipler 18 ay sonra modüler yapılarının erezyona uğramadığını, aksine genişlemeyi kaldırabildiğini ölçüyor. Shopify’ın 800+ mühendisle bu disiplini sürdürebilmesi, modular monolith’in ölçek sorununun teknik değil, kültürel olduğunu kanıtlıyor. Yorumlarınızı ve modular monolith deneyimlerinizi bekliyorum.

Sıkça Sorulan Sorular