Modüler Monolitik Mimari (Modular Monolith Architecture) Nedir? Derinlemesine İnceleyelim…

Merhaba,

Malumunuz eskiden tek bir kod tabanına dayalı monolitik mimari temellerinde yazılım geliştiriyorduk. Haliyle tüm bileşenler tek bir uygulama içerisinde olduğu için debug süreçleri daha kolay, test süreçleri daha basitti. Mikroservisler gibi farklı protokollerle ağ üzerinde çağrılar yapmak yerine, fonksiyonlar doğrudan çağrıldığı için gecikme süreleri de oldukça düşüktü. Monolitik uygulamalar tek bir dosya ya da konteyner olarak dağıtılabilmekte ve böylece kompleks DevOps süreçleri yerine daha az karmaşık deploy süreçleri gerçekleştirilebilmekteydi. Ayrıca tek bir uygulama söz konusu olduğundan, uygulamanın tüm bileşenleri aynı anda güncellenebilmekte, sürüm yönetimi ve yapılandırma süreçleri çok daha kolay bir şekilde gerçekleştirilebilmekteydi. Bunların yanında, uygulamanın tek bir birim olmasından dolayı güvenlik açısından basitlik sağlanabilmekte ve bir yandan da izleme ve loglamada da tüm metrikler tek bir kaynakta toplanabilmekteydi.

Ancak, zamanla anlaşıldı ki monolitik mimarideki uygulamalar büyüdükçe yönetimi zorlaşmakta, özellikle kod hacmi şiştikçe geliştirme ve bakım süreçleri daha da karmaşık hale gelmekteydi. Bundan kaynaklı yeni geliştiricilerin projeye adapte olması zaman almakta ve özellikle belirli bir alanda ihtisasa sahip olan geliştiriciler, ihtisaslarının dışında ortak kod tabanı ve kültürüne adapte olmak zorundaydılar. Monolitik yapılar genellike scale out (yatay ölçeklendirme/horizontal scaling)’a uygun değildi, bundan dolayı uygulamanın tamamını ölçeklendirmek zorunda kalınıyordu. Uygulamanın herhangi bir noktasında meydana gelen bir hata tüm uygulamayı etkiliyor, hatta küçük değişiklikler bile tüm sistemin yeniden derlenmesini ve deploy edilmesini gerektiriyordu.

Evet… esnek değildi, belli bir seviyeden sonra karmaşıklaşma kaçınılmazdı, farklı işlevsellikler ister istemez yüksek bağımlılık sergiliyor ve bundan kaynaklı bir modüldeki değişiklik tüm sistemin yeniden deploy edilmesini gerektiriyor, meydana gelen bir hata yine tüm sitemi etkiliyordu.

Peki ne yapılması gerekiyordu? Uygun olsun ya da olmasın, tüm mimariyi mikroservise mi dönüştürmeliydi? Yani durduk yere network communication, service discovery, load balancing, monitoring ve log management gibi birçok ek terminolojiye ve operasyonel yüke mi göz yummalıydı? Ya da REST, gRPC veya event-driven mekanizmalarına mı boğulmalıydı? Ee hani mikroservis mimarisi her projeye uygun değildi! Monolitiğin getirdiği angaryalardan kaçınalım derken, projenin yapısıyla uygun olmayan mikroservis mimarisini benimsemek ve bundan dolayı hiç ihtiyacımız olmayacak ekstralarla baş etmeye çalışmak ne kadar doğru olacaktı?

Düşünsenize… Asenkron bir iletişim modeline ihtiyaç olmadığı, işlevsel açıdan ölçeklendirme ya da iş yükünün adil dağılmaması gibi dertlerin mevzu bahis olmadığı bir senaryoda sırf yarının olası monolitik enkazından kaçınalım diye mikroservis mantığını uyguluyor ve esasında yukarıda saydığım kavramlarla başın belaya girmesinin dışında servislerin farklı konumlarda bulunmasından dolayı aralarındaki iletişimin ağ üzerinden gerçekleşmesini sağlıyoruz. Ee bu da önceki(monolitik) hale nazaran ek gecikmelere ve yetmiyor transaction yönetimi gibi kritik problemlerin kompleks çözümlerinin uygulanmasına sebep oluyor. Ve daha nice türlü sebeplere…

Ee napcaz la madem! Ne monolitikten yâr oluyor ne de mikroservisten! dediğinizi duyar gibiyim… Tamam, tamam… Kızmayın. Bir fikrim var, gerginliğe gerek yok 🙂

Şöyle ki, geleneksel monolitik uygulamaların basitliğini ve sağlamlığını alalım, mikroservislerin de esnekliğini ve ölçeklenebilirliğini. Ve bunları harmanlayalım. Yani anlayacağınız, mikroservislerideki gibi birbirlerinden bağımsız ve işlevsel açıdan açıkça tanımlanmış sınırlara sahip olan bir modülerlik sağlayan ama bir yandan da tek bir kod tabanında monolitik yapıda olan bir tasarımı tahayyül edelim. Adına da Modüler Monolitik Mimari (Modular Monolith Architecture) diyelim. Oldu mu? Evet, bence de güzel oldu 🙂

Şimdi Modüler Monolitiğin tanımını biraz daha derinleştirerek, şekillendirmeye çalışalım.

Modüler Monolitik Mimari Nedir?

İşlevsel açıdan iyi tanımlanmış sınırları olan, birbirlerinden bağımsız modüllere veya bileşenlere göre yapılandırılan, ancak mikroservis olmayan bir pattern’dan bahsediyoruz. Burada modüller, ilgili/benzer/ortak bağlamdan olan işlevleri bir araya getiren mantıksal sınırlara göre tasarlanıyor, birbirleriyle gevşek bir şekilde ilişkilendiriliyor (loosely coupled) ve public bir API aracılığıyla aralarında iletişim kuruyorlar. Böylece her ne kadar monolitik bir yapıda çalışılıyor olsa da seperation of concerns teşvik edilmiş ve sistemin bütünlüğü önemli ölçüde iyileştirilmiş olunuyor.Yukarıdaki görsele bakarsanız eğer Modüler Monolitik Mimarinin, işlevsel açıdan tutarlı ve gevşek bir şekilde birleştirilmiş olan birçok bağımsız modülden oluştuğunu görebilirsiniz. Bu şekilde bir tanımın sizlere mikroservisleri hatırlatması gayet doğal. Ne de olsa mikroservis mimari, kendi kendine yeten servisleri temsil etmektedir. Modüler Monolitik Mimaride de aynı durum modüller için geçerlidir. Burada modüller arasında kurulacak iletişimin bir şekilde çözüme kavuşturulması gerekmektedir. Haliyle monolitik mimarideki gibi birbirlerini referans vermekten ziyade public bir API üzerinden haberleşmeleri gerekmektedir. Yazımızın sonraki satırlarında bu konunun detayına dair esasında konuşacağımız iki yaygın iletişim modelinden bahsedeceğiz. Şimdilik konuyu dağıtmadan bulunduğumuz bağlamdan devam edelim.

Mikroservislerin cazibesi giderek daha az çekici hale gelmektedir. Ayrıca sektörün deneyimli gazileri, mümkün mertebe bir projeye mikroservis mimarisiyle başlanmaması gerektiğini öğütlemektedir…

Yani anlayacağınız Modüler Mololitik Mimari, operasyonel karmaşıklık olmaksızın mikroservislerin mantıksal mimarisini bizlere sunmakta ve ihtiyaç ya da yapılan kritikler neticesinde verilen kararlar dahilinde mikroservis mimarisine kolayca geçirilebilecek bir altyapı sunmaktadır.

Modüler Monolitik Mimarisinin Zorlukları Nelerdir?

Modüler Monolitik Mimari, çözmemiz gereken birkaç önemli teknik zorluğu beraberinde getirmektedir. Şöyle ki;

Modüler bir mimari inşa edebilmek için modüller;

• Bağımsız ve kolaylıkla değiştirilebilir olmalı,
• Sadece tek bir iş ya da alana konsantre işlevselliği sağlamalı,
• Diğer modüller tarafından erişilebilir ve şeffaf interface’e sahip olmalı.

Ee peki hoca! Bir modülün tamamen bağımsız olması mümkün mü? diye sorduğunuzu duyar gibiyim… Elbette mümkün değil! Yani bahsettiğimiz mimaride bir modül gerçekte tam bağımsızsa bu durum, hiçbir diğer modülle entegre olmadığı anlamına gelecektir. Biz, entegreden kaçan ya da hiç kullanılmayan modüllerden bahsetmiyoruz, bilakis gevşek bir şekilde birleştirilmiş modüler bir yapılanma inşa edelim istiyoruz.

Ayrıca burada modüllerin bağımsızlığına tekrardan dikkat çekmek ve sınırların belirlenmesindeki hassasiyeti özellikle tekrardan vurgulamak istiyorum. Eğer ki modüller kendi aralarında sıkı bir bağımlılığa sahipse bu durumda sınırların yanlış tanımlanmış olması yüksek ihtimalle olasıdır. Ya bu modülleri birleştirmeyi ya da var olan işlevselliklerini tekrar optimize edip -biraz uğraştırıcı olsa da- sınırlarını baştan kurgulamayı düşünmelisiniz.

Unutmayın; bir modül, iyi tanımlanmış bir interface aracılığıyla erişilebilen ilgili/benzer/ortak bağlamdan olan işlevlerin bir grubunu temsil etmektedir.

Önce Monolitik Bir Uygulamayla Başlayın!

Biliyorsunuz ki, son yıllarda mikroservis mimarisinin ciddi revaşta olmasının iki farklı temel nedeni vardır. Biri; bağımsız, kendi kendine yeten ve açıkça tanımlanmış sorumluluk sınırlarına sahip servislerin oluşturulması ve bunların birbirlerinden bağımsız bir şekilde deploy edilebilmesi ve yüksek ölçeklenebilirlik imkanı sağlamasıdır. Diğeri ise; içerik değerinin olmasıdır. Mikroservisi sahada tecrübe etmemiş, esasında ne olduğunu bilmeyen amma velakin sırf adı var, satar la bu diyerek yarım yamalak -sözde- bilgileriyle mikroservis mimarisine dair ahkam kesen sözde eğitim tüccarlarının -özde şark kurnazlarının- olmasıdır. İşte bu udemy’de orada burada birbirlerinden çaldıkları içeriklerle millete senior’luk taslayıp para kazanacam derdinde olan çakallar yüzünden alakalı alakasız tüm proje temellerinde mikroservis furyası aldı başını gidiyor 🙂 Bi de bunların tüketicisi zayıf kitle var ki, aldıkları sözde eğitimlerden algıladıkları 10’da 1’lik kısmıyla hemen konuya dalıyor, ne okuyarak pekiştirme ne de ulan bu doğru mu yanlış mı diyerek doğrulama derdine düşmeden -Türkiye bir yazılımcı kaybetti- edebiyatı yapabilmek için kendine ağlama duvarı inşa edip, an kolluyor 🙂

Neyse, her zaman diyorum ki mikroservis mimari mükemmel değildir! Aklın yolu bir olmanın bir neticesidir ve senaryosuna/gereksinimine/ihtiyacına göre uygulanan ilkeli, planlı ve geniş zaman gerektiren bir yaklaşımdır. Ha yine merak ediyorsan al sana adam gibi bir kaynak. 4 etapta mikroservis mimarisini ele aldığım nadide bir eser. Diğerleri mi? Hepsini boşver 🙂

• A’dan Z’ye Mikroservis Mimarisi Eğitimi – 1. Etap
• A’dan Z’ye Mikroservis Mimarisi Eğitimi – 2. Etap
• A’dan Z’ye Mikroservis Mimarisi Eğitimi – 3. Etap
• A’dan Z’ye Mikroservis Mimarisi Eğitimi – 4. Etap

Velhasıl, her ne kadar kursağınızda kalacağını bilsem de bir gerçek var ki o da, bir projeye başlıyorsanız mikroservislerden ziyade monolitik başlamanızdır. Bunu bir tek ben demiyorum. Martin Fowler abimizde diyor! Şimdi diyeceksiniz ki, iyi de hoca monolitik bir uygulamayı mikroservise çevirmenin bedelini söylemiyorsun ama! Söylemeye gerek var mı? 🙂 Evet, bilindiği gibi ciddi maliyetli bir uğraş. O halde sen de Modüler Monolitik Mimariyle projeye başlamayı düşün 😉 Böylece ihtiyaç olduğu an mikroservis mimarisine geçiş hem kolay olacak hem de geçmesen dahi monolitik mimarinin getirisi olan hengamelerin birçoğundan baştan kurtulmuş olunacak.

Öyle! Umut tüccarı eğitimcilerimizin ve ne tükettiğini bilmeyen bilinçsiz -Türkiye bir yazılımcısını kaybettici- kitlenin yoluna taş koyduk belki ama bu bir gerçek!

Bunun dışında, Google’ın bile bir araştırma makalesinde Modüler Monolitik Mimarinin trendine katılım sağlayan bir tutum sergilediğini söylemekte fayda görmekteyim (bknz : Towards Modern Development of Cloud Applications) Neden mi? Çünkü Google, mikroservislere dair aşağıdaki beş temel sıkıntıya dikkat çekerek nedensellik argümanlarını sıralamaktadır;

• Performans(Performance)
  Servisler arasındaki haberleşme süreçlerinde verilerin serializing işlemlerinin maliyetleri ve ağ üzerinden gönderilmesinin getirdiği ekstradan zamansal yük, performans üzerinde gözle görülür bir etkiye sahiptir.
• Doğruluk(Correctness)
  Servisler arasında yüksek oranda etkileşimin söz konusu olduğu durumlarda, dağıtılmış(distributed) bu sistemin anlık doğruluğu hakkında mutlak bilgi edinmek neredeyse imkansızdır.
• Yönetim(Management)
  Her biri kendi release planına sahip olan birden fazla farklı uygulamanın/servisin ciddi yönetim sorumluluğu söz konusudur.
• Dondurulmuş API’ler(Frozen APIs)
  Bir API geliştirildikten sonra, bu API’ı consume eden servisleri bozmadan değiştirmek ya da onarmak neredeyse olanaksızdır.
• Geliştirme Hızı(Development Speed)
  Mikroservisler özel ihtisasa sahip olan ekipler tarafından geliştirilmelerinden dolayı pratikte oldukça hızlı inşa edilebilirler lakin, bir serviste yapılan değişiklik diğer birçok servisi etkileyebileceğinden dolayı bu da geliştirme hızı açısından ciddi ters etki yaratabilmektedir.

Ayrıca bu konuda daha fazla bilgi, görüş ve argüman edinmek isterseniz Fallacies of distributed computing başlıklı içeriğe de göz atmanızı tavsiye ederim.

Modüler Monolitik Mimarinin Avantajları Nelerdir?

Esasında yazı boyunca buraya kadar Modüler Monolitik Mimarinin avantajlarını ele alarak gelmiş bulunuyoruz. Yine de bu başlık altında ekstralar eşliğinde avantajları tekrar vurgulamak istiyorum. Şöyle ki, Modüler Monolitik yapılanmanın esasında birçok faydası mevcuttur. En basitinden karmaşık deploy stratejileri gerektiren mikroservislere nazaran, modüler bir yapılanma tek bir(monolitik) birim/uygulama olarak deploy edilir. Haliyle monolitik olmasından dolayı modüller arasındaki iletişim ağ gecikmeleri veyahut veri serializing gibi ek yüklerden etkilenmeksizin gerçekleştirilir. Modüler Monolitik yaklaşımıyla geliştirilen uygulamada benimsenen tek bir kod tabanı olacağı için debugging ve geliştirme hızı mikroservise nazaran daha hızlı ve basit olacaktır, ayrıca distributed sistemlerdeki her bir servisin farklı veritabanı kullanmasından kaynaklı ortaya çıkan transaction yönetimi gibi kompleks bir sorumluluk Modüler Monolitik Mimaride söz konusu olmayacak, çünkü tüm modüller ortak veritabanı üzerinden çalışma sergileyecektir. Yani anlayacağınız daha düşük operasyonel karmaşıklık ile projenin ehemmiyeti sağlanacak ve gün gelir ihtiyaç doğrultusunda mikroservise geçiş istenirse, evet, buna da net bir geçiş altyapısı sunmuş olacaktır.

Modüler Monolitik Mimaride, modüller birbirlerinden bağımsız olsalar da tek bir işlevsel uygulama olarak bir bütün/monolitik şeklinde deploy edilirler.

Modüler Monolitik Mimari vs Mikroservis Mimari

Mikroservis, Modüler Monolitik Mimari içindeki mantıksal sınırları fiziksel sınırlara yükselten bir mimaridir.

Mikroservis mimarisi, bizlere bounded context’leri net bir şekilde ayrıştırabilmek için modüler bir distributed strateji sunmaktadır. Bunun distributed olmayan haline ise Modüler Monolitik Mimari diyebiliriz.

Görsel kaynağı : https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

Modüler Monolitik Mimaride Modüller Arası İletişim Yöntemleri

İçerik sürecinde bu konuya temas edeceğimizi önceki satırlarda dillendirmiştik. Haliyle şimdi zamanının geldiğini söyleyebiliriz. Evet, Modüler Monolitik Mimaride modüller arasında yaygın olarak kullanılan iki iletişim modeli mevcuttur. Şimdi gelin her ikisini artıları ve eksileri eşliğinde yaklaşımsal olarak anlamamız gereken noktalarıyla inceleyelim;

• Senkron İletişim Modeli – Synchronous Communication
  Senkrondan kasıt modüller arasındaki ilkel metot çağrımlarıdır. Her modül, senkron iletişim modeline eşlik edebilmek için interface üzerinden bir API sunmaktadır. Hedef modül bu interface aracılığıyla ilgili metodu call eder ve sonuç elde edilene kadar bekler. Haliyle direkt programatik metot çağrımı odaklı olmasından kaynaklı, senkronizasyon eşliğinde hız sürecin en büyük getirisidir.

      public class OrderModule(IInventoryService inventoryService)
      {
          private readonly IInventoryService _inventoryService = inventoryService;
  
          // Senkron iletişim örneği
          public async Task<bool> CreateOrderAsync(Order order)
          {
              // Stok kontrolü - Senkron iletişim
              var stockAvailable = await _inventoryService.CheckStockAvailabilityAsync(order.ProductId, order.Quantity);
              
              if (!stockAvailable)
              {
                  return false;
              }
  
              // Sipariş oluşturma işlemleri...
              return true;
          }
      }
  

  Görüldüğü üzere senkron iletişim modelinde modüller, compile time’da interface’ler aracılığıyla birbirlerine bağlıdırlar. Haliyle runtime’da, dependency injection sayesinde ilgili işlevsellik kolaylıkla çağrılabilmekte ve hiçbir dolaylılık olmaksızın modüller arasında rahatlıkla iletişim süreci gerçekleştirilmektedir.

  Senkron iletişim, modüllerin sıkı bir şekilde bir araya geleceği ve böylece modüllerden biri kullanılmadığı taktirde bu duruma dependent olan modüllerinde etkileneceği anlamına gelmektedir.

• ASenkron İletişim Modeli – Asynchronous Communication
  Modüller arasında duruma göre değişkenlik gösterecek olsa da en ideal haberleşme modeli asenkron iletişim modelidir. Bir modül, hedef modüle message broker aracılığıyla mesajını gönderir ve işlevine devam eder. Hedef modül ilgili mesaja subscribe olur ve kendi iş yoğunluğuna göre işlemeye devam eder.

  Dolayısıyla modüllerin birbirlerini bilmeleri gerekmemekte ancak sadece mesaj kontrakt’larını bilmeleri yetmektedir. Haliyle buradaki public API’ler mesaj kontrakt’larıdır diyebiliriz. Böylece modüller arasındaki iletişim sürecinde hem yüksek kullanılabilirlik hem de loosely coupled söz konusu olmakla birlikte ee ister istemez hafif karmaşıklık oranında da artış gözlemlenebilmektedir. Ayrıca modüllerin haberleşmesi sürecinde message broker kullanılmasından ve iletişim sürecindeki mesajların serializing edilmesinden kaynaklı senkron iletişime nazaran performansta düşüş ve bundan dolayı süreçte maliyet kaçınılmazdır.

  Publisher module;

      public class OrderModule(IMessageBus messageBus)
      {
          private readonly IMessageBus _messageBus = messageBus;
  
          // Asenkron iletişim örneği
          public async Task ProcessOrderAsync(Order order)
          {
              // Stok güncelleme - Asenkron iletişim
              await _messageBus.PublishAsync("inventory.update", new InventoryUpdateMessage
              {
                  ProductId = order.ProductId,
                  Quantity = order.Quantity,
                  Operation = "decrease"
              });
          }
      }
  

  Consumer module;

      public class InventoryModule(IMessageBus messageBus)
      {
          private readonly IMessageBus _messageBus = messageBus;
  
          // Asenkron iletişim için mesaj işleme
          private async Task HandleInventoryUpdate(InventoryUpdateMessage message)
          {
              // Stok güncelleme işlemleri...
              await UpdateStockAsync(message.ProductId, message.Quantity, message.Operation);
          }
  
          private async Task UpdateStockAsync(int productId, int quantity, string operation)
          {
              // Stok güncelleme mantığı...
          }
      }
  

Modüler Monolitik Mimaride Veri İzolasyonu Nasıl Sağlanır?

Modüler Monolitik Mimarideki temel amacımız, monolitik ve mikroservis mimarilerinin eksikliklerini gidermeye çalışmak ve meydana ortanca bir ideale sahip yeni bir yaklaşım koymaktır. Haliyle bunu yaparken, işin içinde bir nebze monolitik yaklaşım olacağı için sistemdeki farklı parçalar/modüller arasında bağımlılık durumları kaçınılmaz olmakta ve böyle bir durumda veri izolasyonu göz ardı edilemeyecek bir nokta olarak karşımıza çıkmaktadır. Bu bilinç doğrultusunda Modüler Monolitik Mimaride, modüller arasında veri izolasyonunu sağlamak için aşağıdaki dört farklı yöntemden biri uygulanabilmektedir;

• Aynı veritabanı, ayrı tablolar.
• Aynı veritabanı, ayrı şemalar.
• Ayrı veritabanları.
• Farklı veritabanları.

Şimdi bu yöntemleri detaylandırmaya başlamadan önce temel ilkeleri masaya yatırmakta fayda görmekteyim. Şöyle ki; mantıken olayı değerlendirdiğimizde, nasıl ki çalışılan bir iş yerinde her bir şube, ekip ya da takım diğerlerinden izole edilmiş bir ortam ve çalışma alanı arzuluyor, aynı ihtiyaç yazılım aleminde modüller için de geçerlidir. Yani mümkün mertebe bir modülün, yalnızca kendine ait tablolara sahip olmayı ve bu tablolara sadece kendisinin erişebilmeyi istemesi en doğal refleksidir diyebiliriz. Doğru mu? Doğru! Bu gayet, modüllerin çalışma rahatlığı ve ehemmiyeti için oldukça doğal bir arzusudur diyebiliriz. Bu gaye doğrultusunda sistemi inşa etmemiz ve bu minvalde pratiksel düşünce üretmemiz veri izolasyonu açısından işimizi oldukça kolaylaştıracak en doğru zemini sağlayacaktır.

Modüller arasında veri izolasyonunu sağlamak, aralarında gevşek bir ilişkilendirme oluştururken (loosely coupled) bir yandan da sistemin olası değişikliklere ya da yeniliklere karşı direncini yumuşatmaktadır.

Aynı veritabanı, ayrı tablolar

En basit veri izolasyon yöntemidir ve neredeyse hiçbir izolasyon olmaksızın veritabanı düzeyinde her bir modüle ait tablo oluşturup, tasarımsal açıdan vur geç yapılmasıdır 🙂 Evet, tüm modüller için tablolar tek bir veritabanında tutulmaktadır. Eee hoca! karışıklık olmaz mı? diye sorarsanız eğer elbet olasıdır, hatta projenin kapsamına göre kaçınılmazdır.

Yine de küçük ve bi tık üstü uygulamalar için ideal bir yöntemdir. Ancak; veritabanı hacminin genişlediği ve tablo sayısının arttığı uygulamalarda modüller arası izolasyon açısından pekte ideal değildir.

Aynı veritabanı, ayrı şemalar

Veri izolasyonunu mantıksal açıdan uyguladığımız yöntemdir. Yine tek bir veritabanı üzerinde, tüm modüllerin tabloları tutulmakta lakin bunlar şemalar vasıtasıyla birbirlerinden mantıksal olarak ayrılmaktadır. Böylece hangi modülün hangi tabloları içeriğini ayırt etmek zahiren kolaylaşmaktadır.

Not : Özellikle EF Core’da, her bir şemaya uygun context oluşturularak kullanılması bu yöntem için ideal bir teknik olacaktır.

public class CatalogDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public DbSet<Category> Categories { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("catalog");
    }
}

public class OrderDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }

    public DbSet<LineItem> LineItems { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("order");
    }
}

Ayrı veritabanları

Modüller arasında katı veri izolasyon kuralları oluşturulması gerekiyorsa artık veritabanlarının ayrılması elzemdir. Her bir modül, bir diğerinden izole edilmiş farklı bir veritabanına odaklı çalışma sergilemekte ve böylece ne tablo ne de şema üzerinden ayırt etmeye gerek kalmaksızın artık gönül rahatlığıyla kendi dünyasında verisel işlemlerini yürütebilmektedir.

Her bir modülün farklı bir veritabanı olması ne kadar özgürlük kazandırıyor olsa da ister istemez ortak bir veritabanına karşın daha fazla operasyonel karmaşıklık getirmekte ve bir yandan da birden fazla veritabanı için altyapı kurgulanmasını ve yönetilmesini gerektirmektedir.

Ancak mevzu bahis modüler bir yaklaşımsa eğer, evet! en doğru ve ideal yöntem ayrı veritabanlar üzerinden tasarımda bulunmaktır diyebiliriz.

Farklı veritabanları

Son olarak da, modüllerin işlevlerine göre farklı veritabanlarının seçilip, veri izolasyonunun daha efektif hale getirilmesini değerlendirelim.

Evet, ayrı veritabanı yöntemini benimserken illa tüm modüller için aynı veritabanı türünü kullanacağız diye bir kaidenin olmadığını ifade etmekte fayda görmekteyim. Kimi modüller, işlevlerine göre relational olan MS SQL ya da PostgreSQL veritabanlarını kullanırken, kimileri de NoSQL olan MongoDB’yi kullanabilir. Artık bu yöntemin mikroservislere kucak açtığı da aşikardır 🙂

Nihai olarak;
Görüldüğü üzere ne monolitik’ten yâr oldu ne de mikroservis’ten her derde deva. Modüler Monolitik Mimari ise günün kahramanından çok, kötünün iyisi gibi oldu 🙂 Evet, hiçbir mimarinin ve yaklaşımın bulunulan şartları ve gereksinimleri gözetmeksizin her uygulama ve çalışamaya dair genellenebilecek şekilde mükemmel olmadığını ve özellikle yazılım camiasında böyle sloganist kabullerin ancak lokalde yapılan ufak tefek denemeler esnasında geçerli olduğunu anladığımızı düşünüyorum! 🙂 Denemeden, test etmeden, yaşam içinde tecrübede bulunmadan bir yaklaşımı mutlak benimsemek, gerçeklere ciddi ket vurmaktır diyebiliriz. Velhasıl, umarım bu mimariye dair sizlere gerekli fikri verebilmiş ve ihtiyaç doğrultusunda gereksinimlere göre doğru kararlar verebilmenize bir nebze destek olabilmişimdir.

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…