Modular Monolith Mimarisi Nedir?

modular monolith, yazılım mimarisinde “hemen mikroservislere geçmeden, modülerliği monolith’in sadeliğiyle birleştirmek” isteyen ekipler için geliştirilmiş bir ara desendir. Bu yaklaşım, klasik monolith’in dağıtım kolaylığını korurken, domain sınırlarını modüller halinde keskin biçimde ayırır. Doğru uygulandığında, ekibiniz büyüdükçe servislere bölme ihtiyacını geciktirir ve geçiş sırasında ciddi yeniden yazım maliyetlerinden kurtarır.

modular monolith nedir ve neden önemlidir?

modular monolith kavramı, ilk olarak 2017-2018 yıllarında Simon Brown ve Sam Newman gibi mimarların yazılarında net biçimde ortaya kondu. Temel fikir şudur: tek bir deploy edilebilir birim içinde, her bir modül kendi domain sınırına sahip olur, modüller arası iletişim doğrudan çağrı yerine iyi tanımlanmış arayüzler üzerinden yapılır, ve her modül ileride bağımsız bir servise dönüştürülebilecek şekilde tasarlanır. Bu, “monolith” etiketinin olumsuz çağrışımını tersine çevirir; artık amaç kasıtlı olarak modüler monolith’i tercih etmektir.

modular monolith hangi durumlarda kullanılır?

Hangi durumlarda tercih edilir: (a) Ekip büyüklüğü 5-20 kişi arasında, (b) Domain karmaşıklığı orta-yüksek, (c) Operasyonel olgunluk mikroservisleri yönetmeye henüz hazır değil, (d) İş süreçleri sık değişiyor ve hızlı refactor gerekiyor. Bu koşullarda saf mikroservis mimarisi operasyonel yükü (service mesh, distributed tracing, eventual consistency) ekibe bindirirken, modular monolith aynı domain bölünmesini monolith’in sadeliğiyle sunar.

modular monolith nasıl yapılır?

modular monolith için temel kavramlar

Modular monolith’in kalbinde üç kavram yatar: bounded context (sınırlı bağlam), module boundary (modül sınırı) ve anti-corruption layer (bozulma-önleyici katman). Bounded context, Domain-Driven Design’dan gelir; her modül kendi domain modeline sahiptir ve diğer modellerin terminolojisini kullanmaz. Module boundary, paket yapısı ve erişim belirleyicileri (private/public modül API’leri) ile fiziksel olarak uygulanır. Anti-corruption layer ise dış sistemlerden veya eski koddan gelen veriyi kendi domain modelinize çevirir.

modular monolith adım adım uygulama rehberi

Adım adım uygulama akışı:

1. Domain analizi: Event storming veya domain storytelling ile ana kavramları ve süreçleri belirleyin.
2. Modül sınırlarının çizilmesi: Hangi kavramlar hangi modüle ait? Hangi modüller arası iletişim var? “Bir modülün değişmesi başka bir modülü zorunlu kılıyor mu?” sorusu sınır testidir.
3. Paket yapısının kurulması: Her modül kendi alt paketinde; dış dünyaya sadece modülün “public” API’si açık. Java/Spring’de module-info.java, .NET’te internal, PHP/Laravel’de namespace + service provider.
4. İletişim kuralları: Modüller arası çağrılar senkron olabilir (in-process) ama asla doğrudan tablolar üzerinden değil, modülün API’si üzerinden olmalı.
5. Veri sahipliği: Her modül kendi tablolarının sahibidir. Başka modülün tablosuna doğrudan erişim yasak.
6. Refactor disiplini: Modül sınırı ihlali lint kurallarıyla otomatik tespit edilir (örneğin ArchUnit, NDepend).

modular monolith ayarları ve dikkat edilmesi gerekenler

modular monolith için gerekli araçlar ve ön hazırlık

Yaygın araçlar: Spring Modulith (Java), NestJS modules (Node.js), Laravel Modules paketi (PHP), Django apps yapısı, ABP Framework (.NET). Hepsinin ortak özelliği: modülü paket olarak zorunlu kılmak, modül sınırlarını test edilebilir kılmak, ileride microservice’e geçiş için strateji sunmak. Hazır framework kullanmak zorunlu değildir; basit projelerde sadece klasör yapısı + namespace disiplini yeterlidir.

modular monolith yaparken sık yapılan hatalar

Yapılan hatalar: (1) Monolith’i sadece klasörlere bölüp “modüler” sanmak, (2) Modüller arası döngüsel bağımlılık (A → B → A), (3) Ortak bir “utilities” paketine her şeyi doldurmak (anti-pattern), (4) Veritabanını paylaşıp her modülün her tabloya erişmesine izin vermek, (5) Sınır ihlallerini code review’a bırakıp otomatik test eklememek. Bunların hepsi farklı şekillerde geri teper; en sinsi olanı paylaşılan veritabanıdır çünkü schema değişiklikleri tüm modülleri etkiler.

modular monolith performans, güvenlik ve SEO etkileri

Performans: in-process çağrılar network’e çıkmadığı için mikroservislere göre 10-50x daha hızlıdır. Ancak ölçeklenebilirlik tek bir process’e bağlıdır; yatay ölçekleme hâlâ mümkündür (stateful bileşenler için Redis/PostgreSQL), ama modül bazlı ölçekleme yapılamaz. Güvenlik: tek process, tek ağ yüzeyi, tek auth katmanı; saldırı yüzeyi mikroservislere göre küçüktür. Operasyon: tek binary deploy, tek log, tek metrik; ekipler için öğrenme eğrisi düşüktür.

modular monolith kontrol listesi ve sık sorulan sorular

modular monolith yayın öncesi son kontrol listesi

Yayın öncesi kontrol listesi:

• Modüller bounded context’lere bölündü mü?
• Döngüsel bağımlılık var mı?
• Her modül kendi tablolarının sahibi mi?
• Modüller arası iletişim sadece public API üzerinden mi?
• Sınır ihlallerini tespit eden lint/test var mı?
• Her modülün ayrı test suite’i var mı?
• Modül, ileride microservice’e çıkarılabilecek şekilde mi?

Sıkça Sorulan Sorular

Modular monolith, mikroservis'ten gerçekten farklı mı?
Evet, mimari olarak farklıdır. Modular monolith tek bir deploy birimi içinde modülerdir; mikroservis ise her modül ayrı process ve ağ üzerinden konuşur. İkisi arasındaki karar operasyonel olgunluğa, ekip büyüklüğüne ve domain karmaşıklığına bağlıdır.

Modular monolith ne zaman mikroservise geçmeli?
Tipik tetikleyiciler: (a) Tek bir modülün ölçeklenme ihtiyacı diğerlerinden çok farklı, (b) Ekip büyümesi nedeniyle deploy çakışmaları sıklaşıyor, (c) Modülün release döngüsü diğerlerinden farklı, (d) Compliance nedenlerle modül izolasyonu zorunlu.

Küçük projelerde modular monolith gerekli mi?
2-3 kişilik ekiplerde ve basit domain'lerde genellikle overkill'dir. Ancak projenin büyüyeceği öngörülüyorsa, baştan modüler başlamak sonradan refactor maliyetini düşürür.

Veritabanı paylaşımı modular monolith'te kabul edilebilir mi?
Evet ama dikkatli olunmalıdır. Her modül kendi şemasına sahip olabilir veya aynı şema içinde kendi tablo önekini kullanabilir. Önemli olan modüllerin başka modülün tablolarına doğrudan sorgu atmamasıdır; tüm erişim modül API'si üzerinden olmalıdır.

Hangi framework'ler modular monolith'i iyi destekliyor?
Java için Spring Modulith, Node.js için NestJS, PHP için Laravel Modules, .NET için ABP Framework, Python için Django apps yapısı iyi seçeneklerdir. Ancak hiçbiri olmadan, sadece klasör yapısı + namespace disiplini ile de uygulanabilir.

Modüler monolith'te test stratejisi nasıl olmalı?
Üç katmanlı test önerilir: (1) Modül unit testleri (her modül kendi başına, diğerlerinden bağımsız), (2) Modüller arası entegrasyon testleri (sınır ihlalleri tespit edilir), (3) Uçtan uca E2E testleri (gerçek akış). Coverage hedefi modül başına %80+, kritik modüller için %90+.

Modülerden mikroservise geçiş kaç gün sürer?
Modülün büyüklüğüne bağlıdır. Tipik bir modül (10-20 endpoint, 5-10 tablo, 1-2 dış bağımlılık) için 2-4 hafta yeterlidir. Geçiş: modülün API'sini HTTP üzerinden açmak, iletişimi sync çağrıdan HTTP'ye çevirmek, veri sahipliğini netleştirmek, dağıtım altyapısını kurmak. Modülerlik disiplini sağlamsa bu süre yarıya iner.

Modüler monolith'te hangi durumlarda bölünme yapılmalı?
Üç net sinyal: (1) Bir modülün response time P95'i diğerlerinin 3 katı ve optimize edilemiyorsa, (2) Modülün release sıklığı diğerlerinden 5x fazlaysa, (3) Modülün veri hacmi diğerlerinden 10x büyükse ve DB sharding gerekirse. Bu sinyallerin hepsi birden olmasa bile, güçlü sinyaller bölünmeyi haklı çıkarır.

Gerçek Dünya Senaryoları

Bir e-ticaret startup'ı düşünün: başlangıçta Laravel monolith olarak kodlandı, 2 yılda 40+ modüle ulaştı, ekip 8 kişiye çıktı. Her modül kendi service provider'ında, her modülün kendi migration'ları, kendi route grubu, kendi test suite'i var. Yeni özellik geliştirme hızı ilk günküyle aynı; bu, modular monolith'in en büyük başarısı. Ekip büyüdüğünde 3 kritik modül (Order, Payment, Inventory) mikroservis olarak çıkarıldı; geri kalan 37 modül hâlâ monolith içinde. Bu "strangler fig" geçiş stratejisi, büyük yeniden yazım olmadan ölçeklenmeyi sağladı.

Bir SaaS ürününde ise senaryo farklı: 12 modül, 6 ayda geliştirildi, her modülün domain uzmanı farklı. Modular monolith sayesinde her modül kendi sorumluluğunda, diğer modüllere minimum bağımlılık. Pazarlama ekibi kampanya modülünü, fatura ekibi billing modülünü paralel geliştirebiliyor; birbirlerini beklemek zorunda değiller.

Bir finans uygulamasında: 15 modül (account, transaction, ledger, reporting, fraud, kyc, vb.), her modülün sıkı compliance gereksinimleri var. Audit trail her modülde ayrı tutuluyor, regülasyon değişikliklerinde sadece ilgili modül güncelleniyor. Monolith olsaydı her regülasyon değişikliği tüm sistemi etkilerdi.

Yaygın Tuzaklar ve Çözümleri

Tuzak 1: "Modüler" sandığınız klasör yapısı aslında modüler değil. Sadece klasör açmak modülerlik değildir; bağımlılık yönü, sınır ihlali kuralları, modül testleri olmalıdır. Çözüm: ArchUnit (Java) veya benzeri dependency rule engine ile sınır ihlallerini otomatik tespit edin.

Tuzak 2: Paylaşılan veritabanı, modülleri gerçekte bağımlı kılıyor. Modül A, Modül B'nin tablosuna JOIN atıyorsa bu bir sınır ihlalidir. Çözüm: her modül kendi şemasına sahip, başka modülün şemasına erişim sadece modül API'si üzerinden.

Tuzak 3: Döngüsel bağımlılık. Modül A → Modül B → Modül A. Build'i imkansızlaştırır. Çözüm: paket seviyesinde dependency graph çıkarın, döngü varsa refactor edin (genellikle ortak bir "shared kernel" çıkarılır).

Tuzak 4: Event'leri senkron çağrılarla taklit etmek. "Event olarak tanımladım ama aslında direkt fonksiyon çağırıyorum" yaklaşımı, modül bağımsızlığını bozar. Çözüm: gerçek event bus veya message queue kullanın (Redis, RabbitMQ, Kafka).

Tuzak 5: "Core" modül her şeyi yutuyor. Utilities, helpers, constants ortak bir core'a yığıldığında core büyüyüp modül bağımsızlığını bozar. Çözüm: her modül kendi helper'ını kendi içinde tutsun, sadece gerçekten domain-agnostic olan şeyler (logger, config loader) core'da.

Gelecek Trendleri

Trend 1: Modül-aware geliştirme araçleri. IDE'ler modüller arası sınırı görsel olarak göstermeye başlıyor; geliştirici "bu sınırı ihlal ediyorsun" uyarısı alıyor. Bu, otomatik lint'in ötesinde bir deneyim sunuyor.

Trend 2: "Modulith" framework'lerin yükselişi. Spring Modulith, ABP, NestJS, Laravel Modules gibi framework'ler artık modülü first-class kavram olarak destekliyor. 5 yıl içinde tüm büyük framework'lerde modül desteği standart hale gelecek.

Trend 3: Otomatik modül çıkarma (extraction). Bir modülün boyutu, bağımlılık sayısı, performans profili izlenip "bu modül artık microservice olabilir" önerisi üretilebiliyor. Hâlâ deneysel ama potansiyeli yüksek.

Trend 4: Hybrid dağıtım. Bir uygulamanın bazı modülleri container, bazıları serverless, bazıları edge function olarak çalışabiliyor. Modular monolith bu hibrit modeli destekleyecek şekilde evrilecek.

Mimari Yaklaşımların Karşılaştırması

Sonuç ve Öneriler

modular monolith, mikroservislere erken geçiş yapmak istemeyen ama uzun vadede dağıtık sistemlerin esnekliğine ihtiyaç duyacak ekipler için ideal bir orta yoldur. Başlangıçta tek bir binary olarak çalışır, ekip büyüdükçe modüller fiziksel olarak ayrılır. Bu geçiş stratejisi “strangler fig pattern” olarak bilinir ve büyük başarı hikayelerine sahiptir. Modülerliği korumak için en önemli şey disiplindir: sınır ihlalleri hoşgörüyle karşılanmamalı, otomatik testlerle korunmalıdır.

İlgili Makaleler

• WordPress Block Theme ile Site Tasarımı Nasıl Yapılır?
• Laravel Route Cache Nedir ve Nasıl Kullanılır?
• Laravel Dosya Yükleme Sistemi Nasıl Yapılır?

Daha fazla bilgi için resmi kaynakları inceleyebilirsiniz: OWASP.