Moduler monolit

Moduler monolit, tek deployable birim olarak kalirken kod tabanini bagimsiz modullere ayiran mimari yaklasimdir. Mikroservis operasyonel yukunu almadan modül sınırları, veri sahipligi ve ekip otonomisi sağlar. Duz monolit ile mikroservis arasinda pragmatik bir orta yol sunar ve birçok kurumsal proje icin optimal baslangic noktasidir.

Moduler monolit nedir?

Tek process, tek veritabanı instance'i (veya schema ayrimi) olabilir; ancak moduller birbirinin ic implementation'ina erisemez. Modül dis API'si açık sozlesmedir: public interface, integration event veya application service facade. Derleme zamaninda modül bağımlılıkları kontrol edilir.

• Deployment birimi: Tek artifact, basit CI/CD.
• Modül sınırları: Namespace, assembly veya proje bazinda.
• Iletişim: In-process call, domain event veya modül API.
• Veri: Paylasilan DB veya schema-per-module.

Mikroservis ile karşılaştırma

Mikroservis bagimsiz deploy, ölçeklendirme ve teknoloji cesitliligi sunar; ag gecikmesi, distributed transaction, service mesh ve gozlemlenebilirlik maliyeti getirir. Moduler monolit bu maliyetleri erteler. Modül sınırları net oldugunda gerekirse secili modül ayri servise cikarilir (extract microservice).

Ne zaman moduler monolit?

Ekip henuz operasyonel olgunlukta degilse, domain hala kesfediliyorsa, trafik tek instance ile karşılanabiliyorsa moduler monolit tercih edilir. Premature microservices sik basarisizlik nedenidir.

Modül yapisi ornegi

src/
  Host/                 # Composition root, DI, middleware
  Modules/
    Catalog/
      Catalog.Domain/
      Catalog.Application/
      Catalog.Infrastructure/
    Ordering/
      Ordering.Domain/
      ...
  SharedKernel/         # Minimal shared primitives

Modül API tasarımı

Her modül dis dunyaya sinirli bir API acar. Diger moduller yalnizca bu API uzerinden iletişim kurar. Internal siniflar internal visibility veya friend assembly ile korunur. Modül API degisiklikleri semver ile yönetilir.

public interface ICatalogModule
{
    Task<ProductDto?> GetProductAsync(Guid id, CancellationToken ct);
    Task<bool> IsProductAvailableAsync(Guid id, int qty, CancellationToken ct);
}

Veri sahipligi modelleri

Single database, schema separation: Her modül kendi schema'sinda tablo tutar; cross-schema join modül ihlali sayilir. Shared database anti-pattern: Tüm moduller ayni tablolara yazar. Moduler monolit icin schema ayrimi veya en azindan tablo sahipligi kurali uygulanir.

Moduller arasi iletişim

Senkron: modül facade uzerinden method çağrısı, düşük gecikme. Asenkron: in-process event bus veya MediatR notification, gevsek baglilik. Dis sistemlerle entegrasyon Infrastructure modulunde kalir.

1. Ayni modül icinde: dogrudan domain çağrısı
2. Komsu modül: modül API veya domain event
3. Uzaktan sistem: ACL + integration event

Composition root ve DI

Host projesi tüm modulleri birlestirir. Her modül AddCatalogModule() extension metodu ile servislerini kaydeder. Moduller birbirini dogrudan DI'da kaydetmez; yalnizca public arayüzler expose edilir.

builder.Services.AddCatalogModule(config);
builder.Services.AddOrderingModule(config);

app.MapCatalogEndpoints();
app.MapOrderingEndpoints();

Mimari testler

Modül A, Modül B'nin Infrastructure'ina referans veremez. SharedKernel minimal kalmali. NetArchTest veya custom analyzer CI'da çalışır. Ihlal PR'da bloklanir.

Transaction sınırları

Cross-modül transaction ayni veritabanında mümkün ama coupling artirir. Tercih: modül basina transaction, moduller arasi eventual consistency event ile. Kritik anlik tutarlılık gerekiyorsa orchestrated saga veya dikkatli tek DB transaction sinirli kullanılır.

Ölçeklendirme yolu

Moduler monolit yatay ölçeklendirme (cok instance) ile baslar. Darbogaz modül tespit edildiginde o modül ayri servise extract edilir. Strangler fig ile trafik yavas yavas yeni servise yonlendirilir. Veri migration en zor adimdir.

Extract microservice checklist

1. Modül API zaten net mi?
2. Veri sahipligi ayrilabilir mi?
3. Event sozlesmeleri hazir mi?
4. Operasyon ekibi deploy izleme hazir mi?
5. Rollback plani var mi?

Build ve derleme performansi

Modül basina ayri assembly paralel derlemeyi hizlandirir. Solution filter ile geliştirici yalnizca ilgili modulu acar. Modül bağımlılık grafigi dongusel ise derleme sırası ve refactoring zorlasir.

Güvenlik ve yetkilendirme

Modül bazinda authorization policy tanimlanabilir. Host katmanı authentication merkezidir. Modül icinde fine-grained yetki domain servisinde kontrol edilir.

Test stratejisi

Her modül kendi birim ve entegrasyon testlerine sahiptir. Moduller arasi contract test modül API uzerinde çalışır. Host seviyesinde smoke test tüm modulleri birlestirir.

Yaygın hatalar

Modül adi var ama sınır yok: her sey her yere erisir. SharedKernel sisme. Cross-modül repository çağrısı. Modül API olmadan internal sınıf kullanımı. 'Geçici' cross-import kalıcı olur.

DDD ve bounded context hizalama

Ideal olarak her bounded context bir modül olur. Küçük context'ler ayni modulde alt namespace olarak kalabilir. Context map modül haritasina donusur.

Operasyonel basitlik

Tek log akisi, tek trace, tek deployment pipeline. Mikroservis operasyonu olmadan debug ve incident response hizlanir. Moduler yapı bu basitligi korurken gelecek bolmeye hazirlik sağlar.

Karar ozeti

Moduler monolit, mikroservis karmasikligi olmadan modül bagimsizligi hedefleyen sürdürülebilir bir mimaridir. Net modül API, veri sahipligi, mimari test ve event tabanli gevsek baglilik ile olgunlasir. Ihtiyaç dogdugunda secili extract ile mikroservise geçiş yolu açık kalir.

Gozlemlenebilirlik

Modül adi log ve metrik etiketlerinde standart olmalidir. Modül bazinda error rate ve latency dashboard'u darbogaz modulu erken gösterir. Bu veri extract kararini destekler.

Özet

Moduler monolit pratikte en cok tavsiye edilen baslangic mimarisidir: tek deploy, çoklu modül, net sınırlar, olculu iletişim. Mikroservis ihtiyaci kanitlandiginda modül sınırları extraction yolunu açık tutar. Duz monolitte yasayan organizasyonlar icin ilk adim modül sinirlarini kod ve test ile zorlamaktir.

Üretim ortaminda mimari disiplin

Mimari kararlar yalnizca tasarım dokumaninda kalmamali; CI pipeline, code review checklist ve otomatik analiz araclari ile gunluk geliştirme akisina gomulmelidir. Bağımlılık ihlali, modül sınırı asimi veya katman ihlali iceren pull request'ler merge edilmeden once duzeltilmelidir. Bu disiplin olmadan en iyi diyagramlar bile zamanla erozyona ugrar.

Metrikler ve geri bildirim

Modül basina değişim sikligi, test coverage, cyclomatic complexity ve build sure metrikleri mimari sagligi gösterir. Ani complexity artisi veya test coverage dususu refactoring ihtiyacinin sinyalidir. Teknik liderlik bu metrikleri sprint review'da is degeri ile birlikte degerlendirmelidir.

Incident post-mortem'lerinde kok neden analizi mimari sınırları da kapsamali. Cross-modül veya cross-layer coupling iceren hatalar ADR veya mimari backlog'a donusturulmelidir. Tekrarlayan ihlaller otomatik lint kurallari ile onlenir.

Üretim ortaminda mimari disiplin

Mimari kararlar yalnizca tasarım dokumaninda kalmamali; CI pipeline, code review checklist ve otomatik analiz araclari ile gunluk geliştirme akisina gomulmelidir. Bağımlılık ihlali, modül sınırı asimi veya katman ihlali iceren pull request'ler merge edilmeden once duzeltilmelidir. Bu disiplin olmadan en iyi diyagramlar bile zamanla erozyona ugrar.

Metrikler ve geri bildirim

Modül basina değişim sikligi, test coverage, cyclomatic complexity ve build sure metrikleri mimari sagligi gösterir. Ani complexity artisi veya test coverage dususu refactoring ihtiyacinin sinyalidir. Teknik liderlik bu metrikleri sprint review'da is degeri ile birlikte degerlendirmelidir.

Incident post-mortem'lerinde kok neden analizi mimari sınırları da kapsamali. Cross-modül veya cross-layer coupling iceren hatalar ADR veya mimari backlog'a donusturulmelidir. Tekrarlayan ihlaller otomatik lint kurallari ile onlenir.

Üretim ortaminda mimari disiplin

Mimari kararlar yalnizca tasarım dokumaninda kalmamali; CI pipeline, code review checklist ve otomatik analiz araclari ile gunluk geliştirme akisina gomulmelidir. Bağımlılık ihlali, modül sınırı asimi veya katman ihlali iceren pull request'ler merge edilmeden once duzeltilmelidir. Bu disiplin olmadan en iyi diyagramlar bile zamanla erozyona ugrar.

Metrikler ve geri bildirim

Modül basina değişim sikligi, test coverage, cyclomatic complexity ve build sure metrikleri mimari sagligi gösterir. Ani complexity artisi veya test coverage dususu refactoring ihtiyacinin sinyalidir. Teknik liderlik bu metrikleri sprint review'da is degeri ile birlikte degerlendirmelidir.

Incident post-mortem'lerinde kok neden analizi mimari sınırları da kapsamali. Cross-modül veya cross-layer coupling iceren hatalar ADR veya mimari backlog'a donusturulmelidir. Tekrarlayan ihlaller otomatik lint kurallari ile onlenir.