Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Onion Architecture: Domain Model Merkezde, Altyapı Dış Halkada
Onion Architecture (Palermo, 2008) uygulamayı bağımsız bir domain model'in etrafına kurar: iç halkalar interface'leri tanımlar, dış halkalar implement eder, tüm coupling merkeze doğrudur ve çekirdek altyapıdan ayrı derlenip çalışabilir. Bookstore'un sipariş kodunu Domain Model, Domain Services ve Application Services halkalarına yerleştiriyor, layered ve Hexagonal'dan farkını, halka-project ilişkisini ve ASP.NET Core Identity örneğini gösteriyoruz.
Hexagonal Architecture (Ports & Adapters): Uygulamayı Dış Dünyadan Yalıtmak
Hexagonal Architecture (Cockburn, 2005), uygulamayı UI, test, batch script ve veritabanından eşit uzaklıkta tutar: dış dünya amaca göre tanımlanmış port'lar üzerinden konuşur, her teknoloji bir adapter ile takılır. Bookstore'da IPlaceOrder driving port'unu Minimal API, console CSV import ve xUnit testiyle, IOrderStore driven port'unu EF Core ve in-memory adapter'la sürüyoruz; ASP.NET Core'un IServer'ı ve altıgenle ilgili yanlış okumalar.
Dependency'leri İçe Çevirmek: Layered Architecture Nerede Tıkanır?
Layered Architecture'da compile-time dependency yukarıdan aşağı aktığı için iş kuralları EF Core'a, SQLite'a ve dış API'lere kilitlenir; çözüm, runtime çağrı yönünü koruyup interface'leri onları kullanan domain project'ine taşıyarak referans okunu içe çevirmektir. Bookstore'da veritabanı olmadan test yazma ve kargo firmasını değiştirme senaryolarıyla, "interface ekledim, oldu" yanılgısı ve Hexagonal, Onion, Clean'in ortak fikri.
Mimariyi Zaman İçinde Korumak: Architecture Erosion ve Fitness Function'lar
Mimari kararlar code review'da değil, her PR'da çalışan fitness function'larla korunur: ArchUnitNET ile kapalı layer kuralı, ratchet'li coupling eşiği ve sorgu sayısını sayan bir performans test'i, build'i geçen ama mimariyi bozan bir PR'ı yakalıyor. Erosion ve drift, fitness function türleri, GitHub Actions adımı ve kategori yol haritası.
Conway's Law: Ekip Yapısı Mimariyi Nasıl Şekillendirir?
Sistemler, onları tasarlayan organizasyonun iletişim yapısını kopyalar: aynı 14 commit katman ekiplerinde %86, akış ekiplerinde %21 oranında birden fazla ekibin koordinasyonunu gerektiriyor. Conway (1968), Inverse Conway Maneuver, Team Topologies'in ekip tipleri ve etkileşim modları, cognitive load ve Bookstore'un 3 kişilik ekip ile 4 stream-aligned ekip için iki farklı doğru mimarisi.
Mimari Stillerin Haritası: Layered'dan Microservices'e Hangi Stil Ne İçin?
Architecture style bir constraint setidir; deployment unit sayısı ve technical/domain partitioning eksenleriyle layered, modular monolith, pipeline, microkernel, service-based, event-driven, space-based, SOA, microservices ve Web-Queue-Worker tek haritaya oturur. Pipeline ve AssemblyLoadContext'li microkernel örnekleri, Bookstore bağlamında kendi stil tablomuz ve Clean/Vertical Slice'ın neden stil değil kod organizasyonu olduğu.
Monolith'i Doğru Anlamak: Single-Process, Modular ve Distributed Monolith
Monolith kötü kod değil, tek deployment unit'tir; asıl sorun Big Ball of Mud'dır ve o tek process'te de, yirmi service'te de oluşur. Single-process, modular ve distributed monolith farkı, internal ile compiler'a korunan module sınırları, beş service'lik senkron zincirin %99,9 hedefini nasıl kaçırdığı ve Monolith First tartışması Bookstore üzerinden.
Layered Architecture: Presentation, Business ve Data Layer'larının Gerçek Sorumlulukları
Layered Architecture'ın asıl vaadi closed layer'ların sağladığı izolasyondur, ama .NET'te ProjectReference varsayılan olarak transitive olduğu için Web, Business üzerinden Data'yı sessizce görür; DisableTransitiveProjectReferences bu kuralı derleyiciye taşır. N-layer ve N-tier farkı, closed ve open layer, sinkhole, DB-centric tasarım ve dependency yönünün sorunu.
Trade-off Düşüncesi: Mimaride Doğru Cevap Yok, En Az Kötü Seçenek Var
Mimaride her seçenek bir characteristic'i başka birinin pahasına kazanır; iş, bedeli görünür kılıp bilinçli kabul etmektir. Bookstore'da sipariş e-postasını senkron göndermek checkout'u SMTP'ye bağlayıp çift sipariş üretirken, Channel<T> ile queue'ya almak checkout'u 1 ms'ye indiriyor ama process kapanınca 3 e-postayı kaybediyor; one-way/two-way door, last responsible moment ve kararın neden'ini yazmak.
Quality Attribute Senaryoları: "Hızlı Olsun"u Ölçülebilir Bir Gereksinime Çevirmek
"Hızlı olsun" gibi bir cümle, SEI'nin altı parçalı quality attribute senaryosuyla (source, stimulus, environment, artifact, response, response measure) ölçülebilir ve test edilebilir bir requirement'a dönüşür. Örnekte ortalama 121 ms ile hedefin altında görünen arama, p95'te 659 ms ile hedefi kaçırıyor; utility tree ile önceliklendirme ve senaryoları teste ve monitoring'e bağlamak.
Quality Attribute'lar: ISO/IEC 25010:2023 ile Architecture Characteristic'leri Tanımlamak
Architecture characteristic'ler sistemin ne yaptığını değil, bunu ne kadar iyi yaptığını anlatır ve ancak bir domain hedefine ve sayıya bağlandığında karar üretir. ISO/IEC 25010:2023'ün dokuz characteristic'i ve 2011'den farkları, FoSA'nın sınıflaması, .NET 10'daki karşılıkları ve Bookstore için seçilen ilk üç characteristic.
Yazılım Mimarisi Nedir? Design'dan Farkı ve Architect'in Rolü
Yazılım mimarisi, sistemin önemli property'lerini belirleyen ve geri alınması pahalı olan kararlardır; design ile arasında kesin bir çizgi değil, stratejik ve taktik uçlu bir spectrum vardır. SEI, ISO/IEC/IEEE 42010 ve Fowler/Johnson tanımları, FoSA'nın üç yasası, architect'in rolü ve kategori boyunca kullanılacak Bookstore örneği.