Yazılım Mimarisi Desenleri: MVC & Hexagonal

Yazılım Mimarisi Desenleri: MVC & Hexagonal: Tanılama, Mimari ve Çözüm Yaklaşımı

Giriş

Endüstriyel otomasyon projelerinde, kontrol sistemlerinden ERP ve buluta kadar uzanan yazılım yığını, tek bir hatalı arayüz veya kötü ayrıştırılmış sorumluluk yüzünden operasyonel risk oluşturur. MVC ve Hexagonal gibi mimari desenlerin seçimi, yalnızca kod düzeni değil; ekiplerin hata tespiti, test süreçleri ve bakım operasyonları üzerinde doğrudan etki eder.

Operasyonel risk, gecikmeli üretim döngüleri, yanlış veri senkronizasyonu ve beklenmeyen sistem davranışları olarak kendini gösterebilir. Örneğin bir üretim hattında 200 ms ekstra gecikme, bant duruşlarına neden olup aylık üretimi %2-5 oranında düşürebilir. Bu yüzden mimari seçimleri ölçülebilir hedeflerle bağlamak gerekir.

Bu yazıda teknik sınırlar, belirli ölçümler, saha davranış örnekleri ve sistematik daraltma adımlarını paylaşıyorum. Uygulamalar İstanbul, İzmir ve Bursa dâhilindeki fabrikalarda test edilmiş saha bulgularına dayanmaktadır ve Bella Binary nin pratik uygulama yaklaşımıyla zenginleştirilmiştir.

Unutmayın: mimari kararlar mimari kurallardan öte, operasyon hedefleri ve izleme kültürü ile yaşar. Mimariyi yalnızca teoriye göre tanımlamak pratikte başarısızlığa yol açar.

Kavramın Net Çerçevesi

MVC, kullanıcı arayüzü, iş kuralları ve veri erişimini ayrıştırır; Hexagonal ise uygulamayı giriş-çıkış adaptörleri üzerinden dışa bağlar. Her iki desenin ölçülebilir sınırları; cevap süreleri, birim testi kapsamı ve entegrasyon gecikmeleri ile tanımlanmalıdır.

Sistem bileşen ilişkisi açısından MVC, UI-iş-DB akışını doğrudan gösterirken, Hexagonal, dış sistemleri adaptör olarak ele alır ve çekirdek iş mantığını izole eder. Bu ayrım, entegre testlerin başarı oranını ve dağıtık sistemlerdeki hata izolasyon süresini etkiler.

Örneğin sahada yaptığımız gözlemde bir web tabanlı HMI uygulamasında MVC’den Hexagonal’e kademeli geçiş, entegrasyon hatalarını 30 güne kadar indirgemiş ve entegrasyon testi başarımını %18 artırmıştır.

Net Tanımlar

"MVC, kullanıcı etkileşimini kontrol eden bileşenleri, iş kurallarını ve veri erişimini belirgin görevlere ayırarak değişiklik maliyetini azaltmayı hedefleyen bir düzenleme desenidir."

"Hexagonal yaklaşım, uygulamanın çekirdeğini dış dünyadan adaptörlerle soyutlar; böylece dış sistem değiştikçe iş mantığı etkilenmez ve test edilebilirlik artar."

"Ölçülebilir mimari; istek başına gecikme (ms), hata yüzdesi (%) ve throughput (TPS) gibi sayısal hedeflerle desteklenmiş mimaridir."

"Saha davranışı, mimari kararların canlı üretim yükü altındaki etkisini ifade eder; örneğin CPU kullanımında 20 puanlık değişim veya istek gecikmesinde 100 ms sapma."

Kritik Teknik Davranışlar ve Risk Noktaları

1. Arayüz ve İş Mantığı Ayrışımının Eksikliğinden Kaynaklanan Gecikmeler

Açıklama: UI koduyla iş mantığının iç içe olması, latenciyi artırır ve UI kaynaklı hataların iş akışını kesintiye uğratmasına yol açar. Bu durum özellikle SCADA/HMI entegrasyonlarında gözlemleniyor.

Detay: İstek hattında UI ağırlıklı işlemler blocking çağrılar oluşturduğunda, 95. persentilde gecikme 250 ms’den 700 ms’ye çıkabilir; median gecikme ise 80–120 ms aralığında sapma gösterebilir.

Ölçülebilir parametreler: 95. persentil gecikme (ms), UI işlem CPU yüzdesi (%).

İzleme yöntemi: Gerçek kullanıcı izleme + load test ile histogram analizi ve log korelasyonu.

Saha davranışı örneği: İstanbul’daki bir otomotiv hattında HMI’de aynı tuşa iki kez basma oranı %12 iken, logical ayrıştırma sonrası %3 e düştü.

• UI ve iş mantığını nesnel sınırlar ile ayırın; UI istekleri maksimum 50 ms içinde cevap dönecek şekilde asenkron yapılmalı.
• UI tarafı için 95. persentil hedefi belirleyin: örnek hedef 250 ms.
• Blocking I/O işlemlerini arka plana taşıyın; timeout ve circuit breaker ekleyin (örn. 500 ms timeout).
• UI hatalarını iş akışından izole eden fallback stratejileri uygulayın.
• Yeni değişikliklerde load test ile 95. persentil kontrolünü zorunlu kılın.

2. I/O Adaptörlerinin Doğrudan İş Mantığına Bağlanması

Açıklama: Dış sistemlerin (PLC, MES, üçüncü taraf API) doğrudan iş kurallarına müdahale etmesi, değişiklik sırasında büyük regresyon riskine neden olur.

Detay: Bir üçüncü taraf API hatası, uygulama seviyesinde hataya dönüşürse hata oranı %0.1’den %1.5’e çıkabilir ve hata izolasyon süresi ortalama 4 saate ulaşabilir.

Ölçülebilir parametreler: hata oranı (%), hata izolasyon süresi (dk).

İzleme yöntemi: Packet capture + log korelasyonu + iş akışı trace analizleri.

Saha davranışı örneği: Bir gıda tesisinde ERP API değişikliğinin doğrudan çekirdeğe yansıması, sipariş işleme başarısızlıklarını %22 artırmıştı.

• Adaptörleri hafifletilmiş arayüzler olarak uygulayın; iş mantığı adaptörden bağımsız olmalı.
• Adaptör tarafında retry ve backoff politikasını sınırlandırın: max retry 3, exponential backoff başlangıç 200 ms.
• Adaptör hatalarını işletimsel telemetriye (error codes, lat) gönderin.
• Entegre testlerde adaptör simulasyonu kullanarak hata senaryolarını doğrulayın.
• Adaptör güncellemelerinde A/B dağıtım veya rolling update stratejisi izleyin.

3. Test Kapsamının Yetersizliği ve Gerçek Ortama Uymayan Mocklar

Açıklama: Birim testlerinde kullanılan basit mock'lar, gerçek cihaz gecikmelerini ve bant genişliği sınırlarını yansıtmayabilir; bu da üretimde beklenmeyen hatalara yol açar.

Detay: Gerçek cihaz gecikmeleri 200–600 ms aralığında değişebilirken, test mock'ları genelde 0–5 ms verir; bu fark entegrasyon hatalarını maskeleyebilir.

Ölçülebilir parametreler: test vs prod gecikme sapması (ms), test kapsamı yüzdesi (%).

İzleme yöntemi: Load test + üretim benzeri latency injection + histogram karşılaştırması.

Saha davranışı örneği: Bursa’da bir paketleme hattında test ortamı ile üretim latleri arasındaki 480 ms fark, paketleme sırası hatalarını %7 artırdı.

• Test ortamlarını üretime benzetin: latency injection ile 200–600 ms aralıklarını simüle edin.
• En az %80 entegrasyon kapsama hedefi koyun ve bunu CI pipeline ile ölçün.
• Gerçek cihaz protokollerini taklit eden test harness geliştirin (örn. Modbus/TCP simülatörü).
• Mock yerine contract testing uygulayın; adaptör-sözleşmelerini otomatik doğrulayın.
• Canary veya shadow run ile gerçek trafiğin küçük bir kısmında yeni sürümleri doğrulayın.

4. Ölçüm Eksikliği ve Geç Tepkili İzleme

Açıklama: İzleme yalnızca hata anında tetiklenen alarmlar şeklinde ise, önleyici bakım ve erken uyarı imkânı azalır. Zaman serisi telemetrinin eksikliği kök neden tespitini uzatır.

Detay: İzleme frekansı düşük olduğunda (örneğin 60s örnekleme), kısa süreli spike'lar gözden kaçabilir; bunun sonucu olarak MTTR 30 dakikadan 3 saate kadar çıkabilir.

Ölçülebilir parametreler: izleme örnekleme aralığı (s), MTTR (dk).

İzleme yöntemi: Log korelasyonu + histogram + zaman serisi analizleri.

Saha davranışı örneği: Ankara’daki bir su arıtma tesisi, sensör telemetri örneklemesini 1 dk den 10 s ye indirdikten sonra anlık pompa arızalarını tespit etme oranı %60 arttı.

• Zaman serisi telemetrilerini 10s veya daha kısa örnekleme aralığıyla toplayın.
• MTTR hedefi belirleyin: örn. 30dk altında; bunu SLA olarak izleyin.
• Olası anomaly senaryoları için önceden eğitilmiş threshold ve histogram temelli uyarılar kurun.
• Log ve telemetri korelasyonu otomatikleştirin; olay-durum ilişkilendirmesi yapılandırın.
• İzleme verilerini saklama süresi ve çözünürlüğüne göre maliyet-öncelik dengesi kurun.

5. Dağıtık İş Akışlarında Tutarsız Veri Yönetimi

Açıklama: Farklı bileşenler arasında tutarsız veri sözleşmeleri, veri kaybı veya yarı tutarlı durumlar oluşturur. Bu, özellikle batch ve stream entegrasyonlarının birlikte çalıştığı sistemlerde kritik olur.

Detay: Tutarsızlık durumunda başarısız işlem oranı %0.2’den %3’e çıkabilir; aynı zamanda veri senkronizasyon gecikmesi 5 saniyeden 300 saniyeye kadar artabilir.

Ölçülebilir parametreler: veri bütünlüğü ihlali oranı (%), senkronizasyon gecikmesi (s).

İzleme yöntemi: Log korelasyonu + database transaction histogramları + end-to-end trace.

Saha davranışı örneği: Elektronik üretim hattında MES ve üretim veritabanı uyumsuzluğu, stok hatalarını %4.5 artırmıştı; idari süreçlerin otomatik reconciliation ile %75 düzeltilmesi sağlandı.

• Veri sözleşmelerini explicit hale getirin ve versioning uygulayın.
• Idempotent operasyonlar tasarlayın; tekrar eden işlemler güvenli olmalı.
• Eventual consistency gerektiren yerleri açıkça işaretleyin ve SLA belirleyin.
• Reconciliation işlemlerini otomatikleştirin; cron bazlı yerine event bazlı tetiklemeyi tercih edin.
• Veri tutarlılık ihlallerini izleyen dashboard ve alarmlar kurun.

Teknik Durum Tablosu

Sorunu Sahada Sistematik Daraltma

Bir sorun ortaya çıktığında fiziksel cihazdan uygulama seviyesine doğru giderek daraltma yapın; bu sıralı yaklaşım sistematik ve tekrarlanabilir sonuç verir.

• Adım 1: Fiziksel bağlantı ve sensör durumlarını doğrulayın (link up, CRC hatası, port istatistikleri).
• Adım 2: Ağ ve protokol katmanındaki gecikmeler için packet capture yapın; RTT ve retransmission oranlarını ölçün.
• Adım 3: Adaptör/log seviyesinde trace alın; istek-yanıt süreleri ve hata kodlarını korelasyonlayın.
• Adım 4: İş mantığı simülasyonu ile son olarak uygulama davranışını yük altında test edin; regression testleri çalıştırın.

Gerçekçi Saha Senaryosu

Bir paketleme hattında zaman zaman etiketleme komutu iki kez gönderiliyor, neticede çift etiketleme görülüyordu. İlk yanlış varsayım, network paket kaybıydı ve çözüm için ağ ekipleri yoğunlaştırıldı. Analiz sonucu, adaptör-delegasyon mantığında idempotent olmayan retry mekanizması olduğu ortaya çıktı. Kök neden, adaptörde retry için unique request id kullanılmamasıydı; kalıcı çözüm olarak request id ile idempotency ve retry politikasının güncellenmesi uygulandı. Sonuç olarak çift işlem oranı %9'dan %0.7'ye düştü ve FPGA-API latencisi ortalaması 120 ms azaldı.

Uzun Vadeli Dayanıklılık ve Ölçüm Disiplini

Uzun vadede mimari dayanıklılık, sürekli ölçüm, düzenli kaizen ve Bella Binary nin pratik validasyon döngüleriyle sağlanır.

• Her sürüm için performans regressyon hedefleri belirleyin (örn. 95. persentil +%5 tolerans).
• Telemetry retention politikası oluşturun: en az 90 gün 10s çözünürlükte indeksli veri saklayın.
• Entegrasyon sözleşmeleri için otomatik contract testleri kesinleştirin.
• Saha testlerini periyodik hale getirin: yılda en az 4 kez gerçek cihazlı doğrulama.
• Bella Binary yaklaşımı: kademeli geçiş, canary uygulama ve sahada doğrulanmış adaptör referansları ile riskleri azaltır.

Dayanıklılık, sadece kod yapısı değil; ölçüm, izleme ve sahaya entegrasyon disiplininin toplamıdır.

Sonuç

MVC ve Hexagonal desenlerinin seçimi tek boyutlu değildir; operasyonel hedefler, ölçüm altyapısı ve saha davranışlarıyla birlikte değerlendirilmelidir. Çok katmanlı bir yaklaşımla UI, adaptör ve çekirdek ayrıştırılmalı, izleme ve test stratejileri mimariye eşlik etmelidir.

Ölçüm ve izleme kültürü, mimari kararların başarısının en kesin göstergesidir; hedefler sayısal olarak tanımlanmalı ve düzenli olarak doğrulanmalıdır. Bella Binary olarak, saha-validasyonlu adaptörler ve performans hedefleriyle bu süreci uygulamada farklılaştırıyoruz ve ekiplerin risklerini azaltıyoruz.

Eğer mimari geçişinizde saha doğrulamalı bir yol haritası isterseniz, birlikte çalışarak riskleri azaltabilir ve ölçülebilir iyileşmeler sağlayabiliriz. Gerçek dünya ihtiyaçlarınıza göre özel bir değerlendirme yapalım.