Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Clean Architecture Ne Zaman Fazla Gelir? Template Kültü, Interface Patlaması ve Pragmatik Yol
Clean Architecture, korunacak iş kuralı olmayan CRUD ağırlıklı, kısa ömürlü ya da tek adapter'lı küçük servislerde fazla gelir; uzun ömürlü, kurallı ve çok adapter'lı bölgelerde ise karşılığını verir. Template kültü ve interface patlamasının belirtileri, aynı Dependency Rule'u tek project ve ArchUnitNET test'leriyle korumak, ve layered bir projeden FreezingArchRule ile kademeli geçiş.
Clean Architecture'ı Test Etmek ve Korumak: Core Test'leri, Adapter Test'leri ve Architecture Test'leri
Clean Architecture'da core'u in-memory adapter'larla veritabanı olmadan, adapter'ları Testcontainers ile üretimdeki SQL Server'a karşı test edersin; Dependency Rule'u ise ArchUnitNET kurallarıyla CI'da kırılmaz hale getirirsin. SQLite'ın gizlediği decimal hassasiyeti sorunu, derleyicinin yakalamadığı ihlaller, Types(true) olmadan hiçbir şey seçmeyen kural tuzağı ve NetArchTest'in 2021'den beri güncellenmediği notu.
Persistence Ignorance ve Infrastructure Adapter'ları: EF Core, HttpClient ve Dış Servisler
Persistence ignorance, domain class'larının hangi veritabanına ve ORM'e yazıldığından habersiz kalmasıdır; EF Core'da mapping'i IEntityTypeConfiguration ile Infrastructure'da tutarsın, ama constructor binding ve getter-only property'ler gibi kurallar domain'in şeklini yine de etkiler. Kargo firmasının API'sini typed HttpClient ile bir driven adapter'a sarmak, dış modeli içeri sızdırmamak ve generic repository ile IQueryable tuzağı.
Application Layer ve Use Case'ler: MediatR Olmadan Handler, Validation ve Transaction Sınırı
Application layer'da her use case tek amaçlı bir handler class'ıdır: input validation Web'de, iş kuralı Domain'de kalır, beklenen hatalar Result ile döner ve tek bir SaveChanges transaction sınırını çizer. Scrutor ile decorator'larla cross-cutting işleri MediatR'sız eklemek ve MediatR'ın 13.0.0 sonrası lisans durumu.
Clean Architecture: Dependency Rule, Use Case'ler ve Sınırı Geçen Veri
Clean Architecture'ın (Martin, 2012) tek kuralı Dependency Rule'dur: kaynak kod dependency'leri yalnız içe bakar ve sınırı entity ya da veritabanı satırı değil, iç çemberin ihtiyacına göre sade bir veri yapısı geçer. Bookstore'da dört çemberin karşılıkları, EF Core satırını döndürmenin yarattığı JSON döngü hatası, output port ve presenter ile ASP.NET Core'daki Result döndüren pragmatik karşılığı ve Hexagonal, Onion, Clean karşılaştırması.
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.