Monolit Mimari Nedir?

Tek bir dağıtım birimi

Monolitin belirleyici özelliği kodun büyüklüğü değil, birlikte yayına alınmasıdır. Bir online mağazada ürün kataloğu, sepet, sipariş ve fatura modülleri aynı projede yaşar; tek bir derleme çıktısı üretilir ve tek seferde canlıya alınır. Modüller arasındaki iletişim ağ üzerinden değil, aynı süreç içindeki fonksiyon çağrılarıyla gerçekleşir.

Sık yapılan bir yanlış, monolitin ölçeklenemeyeceğini düşünmektir. Aynı monolit, önüne bir yük dengeleyici konarak onlarca sunucuda yan yana çalıştırılabilir. Ölçeklemenin sınırı genellikle uygulama kodu değil, ortak veritabanıdır; bu da mimariden bağımsız bir sorundur.

Monolitin hakkı verilmeyen avantajları

• Basit yayın süreci: Tek bir pipeline, tek bir sürüm numarası, tek bir geri alma adımı.
• Tutarlılık kolaydır: Siparişi kaydetmek ve stoğu düşmek tek bir veritabanı işlemi (transaction) içinde yapılabilir; ya ikisi birden olur ya hiçbiri.
• Hata ayıklama ve izleme: Bir isteğin izini sürmek için tek bir log akışı ve tek bir yığın izi (stack trace) yeterlidir.
• Yeniden düzenleme ucuzdur: Bir fonksiyonun imzasını değiştirdiğinizde derleyici veya testler, onu kullanan her yeri aynı anda gösterir.
• Performans: Süreç içi çağrı, ağ üzerinden yapılan bir istekten kat kat hızlıdır ve yarı yolda kopmaz.

Sorunun kaynağı monolit değil, bağımlılıklar

Monolitler kötü ün kazandıysa bunun nedeni çoğu zaman sınırsız büyüyen bağımlılıklardır. Her modülün diğerinin tablolarına doğrudan sorgu attığı, ortak yardımcı sınıfların her şeyi bildiği bir kod tabanında küçük bir değişiklik beklenmedik yerleri bozar. Bu duruma literatürde “big ball of mud” (büyük çamur yumağı) denir ve zamanla teknik borcun en pahalı biçimine dönüşür. Buna eklenen pratik dertler de vardır: test ve derleme süreleri uzar, tek bir modüldeki bellek sızıntısı bütün uygulamayı düşürebilir, en çok kaynak isteyen modül yüzünden tüm uygulama büyük sunuculara taşınır.

Modüler monolit nasıl kurulur?

Modüler monolit, tek birim olarak yayına alınmayı korurken içeride servis sınırları kadar katı sınırlar çizer. Tipik bir klasör yapısı şöyledir:

src/
  modules/
    katalog/
      index.ts        // modülün dışarıya açık tek kapısı
      internal/       // diğer modüller buraya erişemez
    siparis/
      index.ts
      internal/
    fatura/
      index.ts
      internal/
  shared/             // yalnızca gerçekten genel araçlar

Bu yapının işe yaraması için birkaç kural uygulanır:

• Her modül kendi tablolarına sahiptir. Sipariş modülü katalog tablolarına SQL yazmaz; ürün bilgisini katalog modülünün açık fonksiyonundan ister. Ayrı veritabanı şemaları bu ayrımı görünür kılar.
• Sınırlar araçlarla korunur. Lint kuralları veya dilin paket görünürlüğü, başka bir modülün internal klasöründen içe aktarmayı derleme aşamasında engeller. Yalnızca dokümantasyonda kalan kurallar birkaç ay içinde aşınır.
• Yan etkiler olaylarla tetiklenir. “Sipariş oluşturuldu” olayı süreç içinde yayınlanır, fatura modülü bunu dinler. Sipariş modülü faturanın varlığından haberdar olmak zorunda kalmaz.

Monolitten parça ayırmak

Bir modülün gerçekten bağımsız ölçeklenmesi ya da ayrı bir ekip tarafından ayrı takvimle yayınlanması gerektiğinde, iyi sınırlanmış bir modül mikroservise dönüştürülebilir. Yaygın yöntem “strangler fig” desenidir: yeni servis yanına kurulur, trafik adım adım ona yönlendirilir ve eski kod ancak kullanılmaz hâle geldiğinde silinir. Modül sınırları baştan temiz tutulmuşsa bu ayırma haftalar sürer; tutulmamışsa önce monolitin içini düzenlemek gerekir.