Mikroservisler ölçekleme (scaling) sorunlarını çözer, ancak organizasyonel sorunları çözmez. Mimari komitesi legacy sistemi olan Mono'yu bölmeye karar verdiğinde, bunun sadece kodu ayrı repository'lere taşımak ve bir API gateway eklemekten ibaret olduğunu sandılar.
Mono'nun sır sakladığının farkında değillerdi.
Bu bölüm aslında ne hakkında
Bu bölüm, arkeolojik araştırma yapılmadan uygulanan 'strangler fig' (boğan incir) pattern'ının kibri hakkındadır. Legacy sistemler genellikle orijinal geliştiriciler kötü olduğu için değil, iş gerçekliği (business reality) çirkin olduğu için çirkindir. Mono'daki iç içe geçmiş her if ifadesi ve tuhaf veritabanı trigger'ı, beş yıl önce bir yönetici istediği için oradadır.
Teknik Çıkarım
Kod, iş kurallarınızın (business rules) tamamen doğru olan tek dokümantasyonudur. Legacy bir sistemi sıfırdan yeniden yazdığınızda, sadece feature'ları yeniden yazmış olmazsınız; eski sistemin zaman içinde özümsediği tüm edge case'leri ve acı dolu dersleri de kasıtlı olarak unutmuş olursunuz.
Gerçek Takımlarda Nasıl Görünür?
Bunu, %80 tamamlanma oranında takılıp kalan modernizasyon projelerinde görürsünüz. Yeni mikroservisler zariftir, test edilebilirdir, ancak yalnızca Salı günleri oluşturulan belirli bir XML formatına ihtiyaç duyan VIP müşteriyi idare etme konusunda tamamen yetersizdir; bu, BillingProcessor.java dosyasının 4.002. satırı dışında hiçbir yerde belgelenmemiş bir kuraldır.
Takımların dikkat etmesi gerekenler
Mono'nun kötü niyetli olmadığına dikkat edin; o sadece yorgun. O, insanların Jira'ya yazmayı unuttuğu şeyleri 'hatırlıyor'. Bir çiti yıkmadan önce, neden inşa edildiğini anlamalısınız.
Teknik Çıkarım
Legacy kod, genellikle tarihsel iş kurallarının ve edge case'lerin tek güvenilir belgesidir.
Gerçek Takımlarda Nasıl Görünür?
Bu durum, ekibin mevcut monolitin içine gömülmüş domain mantığının (domain logic) karmaşıklığını hafife aldığı 'sıfırdan yeniden yazma' inisiyatifleri sırasında ortaya çıkar.
Sıkça Sorulan Sorular
Bu bölümdeki teknik ders nedir?
Ders, bir monoliti bölmenin sadece veritabanı şemasının etrafına çizgiler çizmekten ibaret olmadığı, derin bir domain bilgisi gerektirdiğidir.
Bu problem neden production'da ortaya çıkar?
Çünkü yeni sistem işin nasıl yürümesi *gerektiğine* göre tasarlanırken, eski sistem işin *gerçekte* nasıl yürüdüğüyle ilgilenir.
Mühendislik ekipleri bu pattern'dan nasıl kaçınabilir?
Strangler Fig pattern'ını dikkatli kullanın, parçaları değiştirmeden önce legacy sisteme karşı kapsamlı entegrasyon testleri yazın ve bazı çirkin kodların bir nedenden dolayı çirkin olduğunu kabul edin.