Son on yılda pek çok ekip, büyüyen uygulamalarını mikroservislere bölmeye çalıştı. Bir kısmı başarılı oldu; bir kısmı ise dağıtık sistemlerin karmaşıklığı, ağ hataları ve operasyon yüküyle boğuştu. 2025 ve 2026'da yazılım mimarisi tartışmalarının sık geçen kavramı bu yüzden modüler monolit oldu: Tek bir uygulama olarak dağıtılan, ama içeride net sınırlarla ayrılmış modüllerden oluşan bir mimari. Bu yazıda modüler monolitin ne olduğunu ve nasıl kurulduğunu anlatıyoruz. Genel karşılaştırma için monolit mi mikroservis mi yazımıza bakabilirsiniz.
Üç mimarinin karşılaştırması
- Klasik monolit: Tek uygulama, tek veritabanı; ama içeride her şey her şeye erişebilir. Zamanla "büyük çamur topu"na dönüşme riski taşır.
- Mikroservisler: Her servis ayrı uygulama, ayrı dağıtım, genellikle ayrı veritabanı. Bağımsız ölçeklenme sağlar; ama ağ, izleme ve veri tutarlılığı karmaşıklığı getirir.
- Modüler monolit: Tek dağıtım, tek süreç; ama modüller birbirinin içine yalnızca tanımlı arayüzler üzerinden erişebilir. Mikroservislerin düzenini, monolitin sadeliğiyle birleştirir.
Modül sınırlarını belirlemek
Modüller teknik katmanlara (Controller, Service, Repository) göre değil, iş alanlarına göre ayrılır. Domain-Driven Design'daki "bounded context" kavramı burada yol göstericidir. Bkz. DDD'ye giriş. Örneğin bir B2B sipariş sisteminde modüller şöyle olabilir:
- Katalog: Ürünler, kategoriler, fiyat listeleri
- Siparişler: Sepet, sipariş, onay akışı
- Cari ve Tahsilat: Müşteri, bakiye, ödemeler
- Stok: Depo, rezervasyon, sevkiyat
- Bildirimler: E-posta, SMS, uygulama içi bildirim
İyi bir sınırın işareti: Bir modülde yapılan değişiklik, diğer modüllerin iç yapısını bilmeyi gerektirmez.
Temel kurallar
1. Her modülün dışa açık bir yüzü olsun
Modüller birbirinin iç sınıflarını değil, yalnızca yayımlanmış arayüzlerini veya sözleşmelerini (contracts) kullanır. .NET'te bunu her modülü ayrı proje yapıp iç sınıfları internal işaretleyerek zorlayabilirsiniz.
2. Veriyi paylaşmayın, sahiplenin
Tek bir veritabanı kullanılsa bile her modülün kendi şeması veya tablo öneki olsun; başka bir modülün tablosuna doğrudan sorgu yazılmasın. Bu kural, gelecekte bir modülü ayrı bir servise taşımayı mümkün kılar.
3. Modüller arası iletişim
- Senkron: Bir modül diğerinin arayüzünü doğrudan çağırır. Basit ve hızlı.
- Olaylar: "Sipariş onaylandı" gibi olaylar süreç içi bir olay yayıncısı ile duyurulur; Stok ve Bildirimler modülleri bu olaya tepki verir. Böylece Siparişler modülü diğerlerini tanımak zorunda kalmaz. Güvenilirlik için outbox deseni ve mesaj kuyruğu düşünülebilir.
4. Mimari testlerle sınırları koruyun
Kurallar yalnızca belgede kalırsa birkaç ay içinde ihlal edilir. NetArchTest veya ArchUnitNET gibi kütüphanelerle "Siparişler modülü, Stok modülünün iç namespace'lerine referans veremez" gibi testler yazılabilir.
.NET'te örnek proje yapısı
src/
Host/ # ASP.NET Core giriş noktası
Modules/
Catalog/
Catalog.Contracts/ # Dışa açık arayüz ve DTO'lar
Catalog.Core/ # İç mantık (internal)
Orders/
Orders.Contracts/
Orders.Core/
Shared/
BuildingBlocks/ # Ortak altyapı: olay yayıncısı, loglamaBu yapı, temiz mimari ilkeleriyle birlikte kullanılabilir: Her modül kendi içinde katmanlı olabilir.
Ne zaman mikroservise geçilir?
Modüler monolit, mikroservise geçişi zorunlu kılmaz; ama kolaylaştırır. Bir modülü ayrı servise çıkarmayı düşündüren durumlar:
- Modülün yükü diğerlerinden çok farklıysa ve ayrı ölçeklenmesi gerekiyorsa.
- Modül farklı bir ekip tarafından, farklı bir hızda geliştiriliyorsa.
- Farklı bir teknoloji veya çalışma ortamı gerektiriyorsa.
Bu durumların hiçbiri yoksa, tek dağıtım biriminin sadeliği çoğu ekip için en büyük avantajdır.
Sık sorulan sorular
Modüler monolit küçük projeler için gereksiz mi?
Çok küçük projelerde fazladan yapı gereksiz olabilir. Ancak birkaç iş alanı içeren ve yıllarca geliştirilecek bir uygulamada baştan modül sınırı koymak ileride büyük zaman kazandırır.
Mevcut klasik monolitimi modüler hale getirebilir miyim?
Evet, aşamalı olarak. Önce iş alanlarını belirleyin, sonra en bağımsız alanı ayrı bir modüle taşıyın ve sınırlarını testlerle koruyun. Bkz. refactoring.
Tek veritabanı performans sorunu yaratmaz mı?
Çoğu iş uygulaması için iyi tasarlanmış tek veritabanı yeterlidir. Performans sorunları genellikle mimariden değil, sorgu ve indeks tasarımından kaynaklanır.
Sonuç
Modüler monolit, "mikroservis mi, monolit mi" ikileminde çoğu işletme yazılımı için en dengeli cevap. Sınırları net modüllerle başlayın, ihtiyaç doğduğunda tek tek ayırın. Uygulamanızın mimarisini birlikte değerlendirmek için bize ulaşın.
