1. GİRİŞ

Modüler monolit mimarisi son yıllarda özellikle orta ölçekli projelerde ve büyümekte olan teknoloji organizasyonlarında dikkat çekiyor. Bulut ve konteyner teknolojilerinin sunduğu olanaklar, mikroservislerin cazibesini artırsa da mikroservislere geçiş her zaman en iyi çözüm değildir. Modüler monolit — tek deployment içinde kalırken güçlü modülerlik, net sınırlar ve ölçeklenebilir geliştirme sağlayan bir yaklaşımdır. Bu makale, mühendislik bakış açısıyla modüler monolitin ne olduğunu, neden tercih edildiğini, nasıl tasarlandığını ve operasyonel olarak nasıl yönetildiğini detaylandırır.

Bu konu neden konuşuluyor?

• Projelerin erken aşamasında mikroservislere atlamak operasyonel yük ve teknik borç yaratabiliyor; modüler monolit bu riski azaltıyor.
• Platform engineering ve iç platform yaklaşımları ekiplerin bağımsızlığını desteklerken, altyapıyı karmaşıklaştırmadan gelişimi sürdürülebilir kılmayı amaçlıyor.
• Performans, tutarlılık ve yönetilebilirlik ihtiyaçları değiştikçe organizasyonlar hibrit çözümler arıyor; modüler monolit bunlardan biri.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Orta büyüklükteki ekipler ve büyüme sürecindeki start‑up'lar
• Mikroservise geçiş maliyetini minimize etmek isteyen organizasyonlar
• Operasyonel olgunluk düzeyi sınırlı olan kuruluşlar

Hangi problemleri çözüyor?

• Dağıtım karmaşıklığını sınırlar — tek artifact ile operasyon kolaylaşır.
• Servis sınırlandırma hatalarından kaynaklanan performans ve tutarlılık sorunlarını azaltır.
• Takımlar arası koordinasyon maliyetini düşürür; aynı zamanda modülerleşme ile paralel geliştirmeye olanak sağlar.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Monolit

Tüm uygulama bileşenlerinin tek bir deployable birim içinde bulunduğu yapı.

Modüler Monolit

Tek deployment birimi korunurken kod tabanının modüller (bounded contexts) halinde katmanlı ve izole şekilde organize edilmesi. Modüller arası erişim kontrollüdür ve iyi tanımlanmış arayüzler (interfaces) kullanılır.

Bounded Context

Domain driven design'de bir modelin anlamlı ve tutarlı olduğu sınır; modüler monolitte servis benzeri bölümler için kullanılır.

Module / Component

Tek bir iş sorumluluğunu kapsayan, bağımsız geliştirilebilir ve test edilebilir kod grubu.

2.2 Mimari bileşenler

• Core domain modules: İş kurallarını barındırır; dışa bağımlılık minimumdur.
• Infrastructure layer: Veritabanı, mesajlaşma, dış API entegrasyonları gibi altyapı bağımlılıkları burada toplanır.
• API / Presentation layer: Dış dünyaya açılan HTTP/gRPC/CLI gibi arayüzler.
• Shared libraries: Ortak util, DTO, validation gibi paylaşılan kodlar; dikkatli yönetilmelidir.

2.3 Terminoloji ve kurallar

• Sınırların belirlenmesi: Modüller arası erişimin sadece iyi tanımlanmış API'ler üzerinden olması.
• Enforcer/Anti‑corruption layer: Yabancı model veya üçüncü taraf API'lerle etkileşimde kullanılır.
• Internal contracts: Modüller arası iletişim için interface ve contract'ların versiyon yönetimi.

3. NASIL ÇALIŞIR? — Teknik Mimari

3.1 Sistem mimarisi

Modüler monolitte uygulama tek bir runtime/process veya aynı deployment unit içinde çalışır. Mimari hedef, kod ve veri bağımlılıklarını modüller arası gevşek ilişki (loose coupling) ile düzenlemektir. Modüller birbirlerine doğrudan veri tabanı tabloları aracılığıyla değil, açık API'ler veya domain event'ler üzerinden erişir. Böylece ileride gerektiğinde modüllerin bağımsız servislere dönüştürülmesi kolaylaşır.

3.2 Bileşenler ve sınırlar

İyi tasarlanmış bir modüler monolit şu kuralları izler:

• Her modül net bir sorumluluk alanına sahip olmalıdır (single responsibility).
• Modül arayüzleri (API) açıkça tanımlanmalı ve paketlenmiş olmalıdır.
• Veri erişimi modül sınırları içinde kalmalı; diğer modüller kendi veri modellerine erişmemelidir.
• Bağımlılıklar tek yönlü olmalı: altyapı katmanı core katmana bağımlı olamaz; tersine core altyapıya bağımlıdır.

3.3 Veri akışı ve veri modelleme

Modüler monolitlerde genellikle tek bir veritabanı kullanılır; ancak mantıksal modelleme modüller bazında ayrıştırılır. Transaction'lar ACID garantisiyle sürdürülürken, modül sınırları içinde transaction kullanımı tercih edilir. Modüler monolitin avantajı, tutarlılığı koruyarak dağıtık transaction ihtiyacını ortadan kaldırmasıdır.

Veri modellemede şu yaklaşımlar öne çıkar:

• Her modülün kendi schema veya schema namespace'i olması (örn. PostgreSQL schema'ları) — mantıksal ayırma sağlar.
• Shared table kullanımından kaçınmak; gerekirse view veya anti‑corruption layer ile erişim sağlamak.
• Event publishing: kritik iş akışlarında modüller event publish ederek diğer modülleri bilgilendirir; bu, eventual consistency senaryolarında kullanılabilir.

3.4 İletişim ve entegrasyon

Modüller synchronous çağrılar (function calls, internal API) veya asynchronous mekanizmalar (in‑process event bus, message broker) kullanabilir. Önemli olan bağımlılıkların yönetilmesidir. In‑process event bus, performans avantajı sağlar ancak yanlış kullanıldığında modüller arası sıkı bağ oluşturabilir.

3.5 Deployment ve CI/CD

Tek bir deployable artifact olduğu için deployment pipeline daha basit görünür. Ancak pipeline içinde modüler testler, contract testleri ve bağımsız smoke test'ler olmalıdır. CI aşamasında modül bazlı test paralelleştirmesi, bağımlılık grafiği ile değiştirme etkisi analizleri (impact analysis) yapılmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix, Amazon, Uber örnekleri — pragmatik yaklaşımlar

Büyük ölçekli firmalar genelde tam mikroservis veya tam monolit yerine hibrit stratejiler uygular. Netflix ve Amazon tarihsel olarak mikros ervislere geçmiş olsa da geçiş süreçlerinde modüler monolit yaklaşımlardan faydalandılar. Özellikle çekirdek domain'lerde modüler monolit kalıp, yeni geliştirilen ve hızla değişen alanlar mikroservislere taşındı.

Küçük ve orta ölçekli organizasyonlar

Orta ölçekli şirketlerde modüler monolit tercih edilmesinin başlıca nedenleri operasyonel basitlik, düşük altyapı maliyeti ve hızlı iterasyon kabiliyetidir. Gerçek dünya örneklerinde, finansal uygulamalarda çekirdek ödeme işlevleri modüler monolit içinde güvenle yönetilirken, analitik ve raporlama servisleri ayrı servisler olarak ayrılabiliyor.

OpenAI, Stripe tarzı uygulamalar

Yüksek güvenlik ve veri tutarlılığı gerektiren servislerde modüler monolit mimari sıkça tercih edilir çünkü transaction garantileri ve tutarlılık sağlamak daha kolaydır. Stripe benzeri ödeme altyapılarında kritik parçalar modüler monolit olarak kalırken, çevresel servisler (metrics, analytics) ayrı dağıtılır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Basit operasyon: Tek deployable artifact, daha az dağıtım karmaşası ve düşük devops maliyeti.
• Tutarlılık: Transactional integrity ve veri tutarlılığı daha kolay sağlanır.
• Geliştirici deneyimi: Lokal debugging ve end‑to‑end testler daha kolaydır.
• Kademeli geçiş imkanı: İleride ihtiyaç duyulursa modülleri bağımsız servislere dönüştürmek daha yönetilebilir.

Sınırlandırmalar

• Tek hata domaini: Tek runtime tüm modülleri etkileyebilir; adece iyi izleme ve failover ile sınırlanabilir.
• Takımlar arası bağımlılıklar: Eğer modül sınırları kötü belirlenirse takım bağımlılıkları artar.
• Ölçeklenebilirlik sınırları: Donanım seviyesinde dikey ölçekleme gerekebilir; bazı durumlarda microservice mimarisi kadar ince ölçeklenme mümkün olmayabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Modül sınırlarını iş odaklı (DDD bounded contexts) olarak belirleyin.
• Shared libraries kullanımını minimize edin; cross‑cutting concerns için iyi tanımlanmış altyapı katmanları oluşturun.
• Contract testing ve API versioning uygulayın; modüller arası sözleşmeleri kodla birlikte versiyonlayın.

Performans optimizasyonu

• In‑process çağrıları basit ve hızlı tutun, fakat modüller arası heavy iş yüklerini asynchronous queue'lara yönlendirin.
• Cache stratejilerini modül sınırlarına göre tasarlayın; cache invalidation politikalarını açıkça belirleyin.

Güvenlik

• Modül sınırları içinde yetkilendirme ve doğrulamayı uygulayın; her API çağrısında token/claim doğrulaması yapın.
• Infrastructure access'lerini (db credentials, secrets) merkezi secret store ile yönetin; least privilege ilkesini uygulayın.

Ölçeklenebilirlik ve operasyon

• Observability: distributed tracing yerine modül seviyesinde ayrıntılı log ve trace sağlayın; trace correlation id kullanın.
• Feature flag'ler ile yeni modül rollout'larını aşamalı yapın.
• Performans sınırı geldiğinde belirli modülleri microservice'e dönüştürme planı oluşturun (strangler pattern).

8. SIK YAPILAN HATALAR

• Modülerlik yerine yüzeysel paketleme: Paketleme sadece klasör veya namespace ayırmak değildir; sınırlar ve bağımlılıklar yönetilmelidir.
• Shared database tablolarının serbest kullanımı — modüller arası tight coupling yaratır.
• Yetersiz contract testing: Modül API'leri değiştiğinde consuming kod kırılabilir.
• Observability eksikliği: Tek runtime olması, dağıtık sistemlerde olduğu kadar görünürlük sağlamazsa debugging zorlaşır.

9. GELECEK TRENDLER

1. Platform engineering'in yükselişi: Internal developer platform'lar modüler monolitleri destekleyecek self‑service araçlar sunacak.
2. Serverless ve modüler birleşimi: Modüler monolit içindeki belirli iş parçaları serverless fonksiyonlara taşınarak hibrit modeller ortaya çıkacak.
3. AI destekli tasarım optimizasyonu: Kod bağımlılık analizleri ve modül sınır önerileri otomatikleştirilecek.
4. Polymorphic deployment: Aynı kod tabanından hem monolit hem de microservice olarak çalıştırılabilecek deployment stratejileri gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Modüler monolit ile mikroservis arasındaki en önemli fark nedir?

   En önemli fark deployment birimidir: modüler monolit tek deployment ile kalır fakat kod ve veri modeli modüllere ayrılmıştır; mikroservisler ise fiziksel olarak ayrı deployable birimlerdir.

2. 2. Hangi durumda modüler monolit tercih etmeliyim?

   Eğer ekip sayısı sınırlıysa, operasyonel olgunluk düşükse veya veri tutarlılığı kritikse modüler monolit daha uygun olabilir. Ayrıca hızlı prototipleme ve düşük maliyet için idealdir.

3. 3. Modüller arası iletişim nasıl sağlanmalı?

   İç API'ler, in‑process event bus veya asenkron messaging kullanılabilir. Önemli olan, contract'ların açık ve versiyonlu olmasıdır.

4. 4. Shared library kullanımı nasıl yönetilmeli?

   Shared library'ler küçük tutulmalı ve domain bağımsız utility'lerle sınırlanmalıdır. Domain mantığı paylaşımı yerine modüller arası interface'ler tercih edilmelidir.

5. 5. Modüler monolitten mikroservise geçiş nasıl yapılır?

   Strangler pattern uygulanarak belirli modüller bağımsız servisler haline getirilir. Öncelik, en fazla bağımsız çalışabilecek ve yüksek yük altındaki modüllere verilmelidir.

6. 6. Veri tabanı yönetimi nasıl olmalı?

   Tek veritabanı kullanılıyorsa schema seviyesinde ayrım veya tablo ownership politikaları uygulanmalı. Kritik durumda modül kendi veri deposuna geçiş planı olmalıdır.

7. 7. Test stratejisi nasıl olmalıdır?

   Unit testler, modül bazlı integration testler ve contract testleri (consumer/provider) kullanılmalıdır. End‑to‑end testler production‑benzeri ortamda düzenli çalıştırılmalıdır.

8. 8. Operasyonel gözlemlenebilirlik için ne yapmalıyım?

   Structured logging, trace id propagasyonu, modül bazlı metrikler ve alert kuralları oluşturun. Tek runtime olması tracing'i basitleştirir ama doğru correlation olmazsa fayda azalır.

Anahtar Kavramlar

Bounded Context

Domain'in tutarlı olduğu sınır; modül sınırlarını belirlemede kullanılır.

Strangler Pattern

Mevcut monolit uygulamayı kademeli olarak yeni servislerle değiştirme yaklaşımı.

Anti‑corruption Layer

Farklı model veya üçüncü taraf sistemle etkileşimde kullanılan adaptör katmanı.

Contract Testing

Modüller arası API sözleşmelerinin doğrulanması; değişikliklerin tüketiciyi kırmaması için gereklidir.

Öğrenme Yol Haritası

1. 0–1 ay: Domain‑driven design (DDD) temel kavramlarını öğrenin; bounded context'leri tanımlama pratiği yapın.
2. 1–3 ay: Modüler monolit örneği geliştirin: tek proje içinde modüller ayırın, internal API ve contract test'leri ekleyin.
3. 3–6 ay: Event driven design, in‑process event bus ve asenkron iletişim desenlerini uygulayın; test ve observability araçları entegre edin.
4. 6–12 ay: Strangler pattern ile kademeli microservice geçişleri, platform engineering ve deployment stratejileri üzerinde deneyim kazanın.