Mimari
Sistem tasarımının dili ve kararları.
Mimari neleri kapsar
Yazılım mimarisi, bir sistemin yapısına dair değiştirilmesi pahalı olan kararların bütünüdür. Bu kategori; sınırların nasıl çizileceğini, bileşenlerin nasıl ayrıştırılacağını ve kararların nasıl bilinçli olarak verileceğini ele alır.
Bu kategorinin kapsamı
- Modüler monolitler ve mikroservisler
- Olay güdümlü mimari
- Bounded context'leri doğru ayrıştırmak
- Anti-pattern: dağıtık monolit
Bu konudaki teknik rehberler.
Her önerinin avantajlarını, maliyetlerini, sınırlamalarını ve hangi koşullarda farklı bir seçimin uygun olduğunu açıklayan ayrıntılı teknik rehberler.
On yıl sonra hâlâ çalışan yazılım
Yazılımın uzun vadeli bakımını belirleyen mimari kararlar: bağımlılıklar, geri alınabilirlik, işletim ve standartlar. Her yaklaşımın avantajları ve sınırlamalarıyla.
Öngörüden önce geri alınabilirlik
Gelecekteki ihtiyaçların tümünü öngöremezsiniz. Değişiklik maliyetini düşük tutmak için hangi kararların dikkatle alınması ve geri alınabilir tasarlanması gerektiğini açıklıyoruz.
İş mantığı controller'a ait değildir
İş kuralları neden controller'a değil, framework'ten bağımsız bir domain katmanına aittir: belirtiler, bakım maliyetleri, test edilebilirlik, migrasyon.
Modüler monolit mi, mikroservisler mi?
Bir inanç savaşı değil, karmaşıklığın nereye dağıtılacağına dair bir karar: Modüler monolit nedir ve mikroservisler ne zaman nesnel olarak daha iyidir?
Yenilikten önce olgun teknoloji
Modaya uymadan teknoloji seçimi: Olgunluk neden başkalarının hataları çoktan bulmuş olması demektir — yeni olan neyi gizler, buna rağmen ne zaman doğrudur. Bağlam ve kullanım ömrü.
Build, Buy ya da Configure — özel yazılım ne zaman kârlıdır
Kendin geliştir, satın al ya da yapılandır — cevap 'satın al' olsa bile dürüstçe. Ölçüt: farklılaşma ve ömür, gizli maliyetler.
Yazılım projeleri gerçekte neden başarısız olur
Yazılım projeleri nadiren teknoloji yüzünden başarısız olur; mühendislik kararları, problem anlaşılmadan önce geri dönüşsüz hâle geldiği için başarısız olur.
Sunucu tarafı render mı, SPA mı
Sunucu tarafı render mı, SPA mı — on yıllık bakım kolaylığını belirleyen frontend seçimi. Modaya göre değil, etkileşim düzeyine ve ömre göre.
Big bang olmadan legacy modernizasyonu
Canlı bir sistem yeniden yazım yerine artımlı ve geri alınabilir biçimde nasıl değiştirilir: Strangler Fig, Anti-Corruption Layer, veri taşıma, paralel işletim.
Bir legacy sistemi devralmak — ilk 90 gün
Sizin geliştirmediğiniz bir sistemi devralmak: değiştirmeden önce anlamak, ilk müdahaleden önce güvenlik ağları, sistemin haritası, davranışı kayıt altına almak.
Rewrite ne zaman yanlış karardır
Bir rewrite neden gömülü bilgiyi çöpe atar ve hareketli bir hedefin peşine düşer, yeniden yazım ne zaman yine de doğrudur — ve kademeli yenileme neden neredeyse her zaman daha iyidir.
Bu konudaki proje deneyimleri.
Gerçek projelerde karşılaşılan sorunlar ve çıkarılan dersler. Müşteri adlarını paylaşmadan teknik deneyimlerimizi aktarıyoruz.
5000 satır kopyala-yapıştır
Bir Mühendislik Hikâyesi: Yaklaşık 5000 satırlık kopyalanmış kod nasıl oluştu, tekrarın pahalı hâle geldiği anı neden kimse fark etmedi — ve kodu yaklaşık onda birine indirmek bize DRY hakkında ne öğretti.
Bu iş çabucak yapılır.
Bir Mühendislik Hikâyesi: Tek bir cümle neden güvenilir bir uyarı işaretine dönüştü ve Batunet bu şekilde başlayan projeleri bugün neden bilinçli olarak reddediyor. Atlanamayacak analiz ve mimarinin değeri üzerine.
Bir kez kopyalamaya başlayınca.
Kopyalamanın kendi dinamiği üzerine bir Mühendislik Hikâyesi: Savunulabilir bir ilk kopyadan nasıl yaklaşık 5000 satır neredeyse aynı kod ortaya çıktığı, tehlikeli kararın neden ilk kopya değil, ikincisinde verilmeyen karar olduğu — ve kodu yaklaşık onda birine indiren konsolidasyonun bize doğru zamanlama hakkında ne öğrettiği.
Yeniden yazmadan gerçek zamanlılık
Bir Mühendislik Hikâyesi: Yıllar içinde büyümüş bir sistemin birden gerçek zamanlı güncellenmesi gerekiyordu — mimarisinin hiç tasarlanmadığı bir gereksinim. Cevabın neden yeniden yazım değil, tek bir veri akışının hedefli olarak yeniden kurgulanması olduğu. Yerel bir gereksinim ile küresel bir yeniden yapılanma arasındaki fark üzerine.
Yönü erken değiştirmek
Bir Mühendislik Hikâyesi: Plan, mevcut bir sistemi genişletmekti. Çalışma sırasında her yeni işlevin karmaşıklığı artıracağı görüldü. Plana bağlı kalmak yerine yön değiştirildi ve işlevler bağımsız API'ler olarak ayrıştırıldı. Geçerliliğini yitirmiş bir planı savunmanın maliyeti üzerine.
Ürün olmayan prototip
Bir Mühendislik Hikâyesi: Bir müşteri yalnızca bir fizibilite kanıtı istedi. Ortaya kullanılabilir bir arayüz çıktı. Ardından proje durduruldu. Fizibilite çalışması ile ürün geliştirme arasındaki fark ve bu farkın neden en baştan adının konması gerektiği üzerine.
Yazılım asla bitmez
En uzun süredir devam eden müşteri projesinden bir Mühendislik Hikâyesi: Gereksinimler sürekli değişir, yazılım asla bitmez — ve buna verilebilecek tek sağlam yanıt, değişikliği ucuz kılan bir mimaridir. Bir son durum fikrinden vazgeçmek üzerine.
Karmaşıklık eklemek yerine kaldırmak
Bir Engineering Story: Harici API bileşenleri monolitin içine gömülüydü. Bunlar ayrıştırılıp bağımsız API'lere dönüştürüldü — sonuç daha net bir mimari ve bağımsız ölçeklenme oldu. Çıkarmanın neden çoğu zaman eklemekten daha değerli olduğu.
Bu kategorideki yazılar düzenli olarak yayımlanıyor. Temel kavramları şimdiden sözlükte bulabilirsiniz.
Sözlüğe gitİlgili teknik içerikleri inceleyin.
Konuyu derinleştiren kavramları, mimari kararları, uygulama kılavuzlarını ve değerlendirmeleri birlikte inceleyin.
Hizmetler
Mühendislik kararları
Uygulama kılavuzları
Bu alanda somut bir sorununuz mu var?
Sorunun teknik çözümünü, uygulamayı geliştirecek ekiple birlikte değerlendirin.
