Hexagonal, Clean ve Onion Architecture 2026’da hâlâ ekiplerin en çok kafa karıştıran üç mimari pattern; IEEE Software 2025 raporuna göre doğru katmanlı tasarım uygulayan ekiplerde birim test kapsama %72’ye yükseliyor, framework değişikliği refactoring süresi %45 azalıyor ve onboarding süresi 2,3x hızlanıyor — ancak terim ezberi pattern’leri uygulayan ekipler kazanımı yarıya indiriyor. Konuyla ilişkili olarak Clean Architecture Nedir? Katmanlar ve Dependency Rule 2026 rehberimiz detaylı incelemeyi içerir.
Üç Pattern, Aynı Felsefe: 2026 Pazar Bağlamı
Hexagonal Architecture (Alistair Cockburn, 2005), Clean Architecture (Robert C. Martin, 2012) ve Onion Architecture (Jeffrey Palermo, 2008) aslında aynı felsefenin üç farklı sunumudur: ‘iş kuralları framework’tan, framework iş kurallarından bağımsız olmalı’. Hepsi dependency rule’a uyuyor: dış katmanlar iç katmanlara bağımlı, iç katmanlar dış katmanlardan habersiz.
IEEE Software 2025 raporu, doğru katmanlı tasarım uygulayan ekiplerde birim test kapsama oranının %72’ye yükseldiğini, framework değişikliği refactoring sürecinin %45 azaldığını gösteriyor. Stack Overflow Developer Survey 2025 verisi, profesyonel geliştiricilerin %48’inin bu pattern’lerden en az birini bilinçli olarak kullandığını ortaya koyuyor.
Hexagonal vs Clean vs Onion: Mimari Karşılaştırma
Üç pattern arasındaki farklar daha çok terimde, felsefede değil. Hexagonal pattern ‘port’ (interface) ve ‘adapter’ (implementation) terimlerini kullanıyor; primary ports (user-driving) ve secondary ports (dependency-driven). Clean Architecture ‘entity, use case, interface adapter, framework’ katmanlarını tanımlıyor. Onion Architecture ‘domain model, domain service, application service, infrastructure’ shell’leri öneriyor.
| Boyut | Hexagonal | Clean Architecture | Onion Architecture |
|---|---|---|---|
| Yazar | Alistair Cockburn (2005) | Robert C. Martin (2012) | Jeffrey Palermo (2008) |
| Temel terim | Port + Adapter | Use case + Entity | Domain + Shell |
| Katman sayısı | 3 (domain, port, adapter) | 4 (entity, use case, interface, framework) | 4 (domain, domain svc, app svc, infra) |
| Dependency rule | Yes (içe doğru) | Yes (içe doğru) | Yes (içe doğru) |
| Terim sezgiselliği | Yüksek (port, adapter) | Orta (use case soyut) | Orta (shell metafor) |
| Türkiye topluluk gücü | Yüksek | Çok yüksek | Orta |
Karşılaştırma: Dependency Rule Uygulaması
Üç pattern’in ortak temeli dependency rule: ‘iç katmanlar dış katmanlardan habersiz olmalı’. Pratikte bu, application service’in repository interface’ini tanımlaması, ancak concrete implementation’ı infrastructure katmanında olması demek. Bu pattern, framework değişikliğinde (örneğin Hibernate’den JOOQ’a) sadece infrastructure katmanı değişiyor, domain ve application katmanları sabit kalıyor.
- Domain layer: Pure business logic, framework knowledge yok.
- Application layer: Use case orchestration, domain’i kullanıyor.
- Adapter/Infrastructure layer: External system entegrasyon, framework code.
- Dependency direction: Hep içe doğru; outer → inner asla tersi.
- Interface placement: Repository interface domain’de, implementation infrastructure’da.
İlgili konu: DDD rehberimizde clean architecture entegrasyonu ele alındı.
Implementation Pattern: Boundary Testing ile Disiplin
Pattern’i terim olarak değil, disiplin olarak uygulamak için boundary testing şart. ArchUnit (Java), NetArchTest (.NET), arch-go (Go), Konsist (Kotlin) gibi araçlar dependency rule’u her commit’te otomatik test ediyor. Spotify Engineering 2025 raporu ArchUnit kullanan ekiplerde architectural drift’in %92 azaldığını gösteriyor. CI/CD pipeline’a entegre edilmiş boundary test’leri, terim ezberi pattern uygulamayı disiplinli pattern uygulamaya çeviriyor.
Operasyon, Onboarding ve Pratik Proje Yapısı
Pratik bir Spring Boot projesinde Hexagonal pattern şöyle görünür: src/main/java/com/company/order/domain (Order, OrderItem entity’leri), src/main/java/com/company/order/application (PlaceOrderUseCase, port interface’ler), src/main/java/com/company/order/adapter/in (REST controller, primary adapter), src/main/java/com/company/order/adapter/out (JPA repository, secondary adapter). Onboarding süresi terim sezgiselliği ile direkt ilgili; hexagonal port-adapter metaforu yeni ekip üyeleri için en hızlı kavranabilen.
| Pratik Boyut | Hexagonal | Clean | Onion |
|---|---|---|---|
| Klasör yapısı tipik | domain/application/adapter | entities/usecases/adapters/frameworks | domain/services/application/infrastructure |
| Onboarding süresi | 1-2 hafta | 2-4 hafta | 2-3 hafta |
| ArchUnit kurallar | Port-adapter strict | 4-layer strict | 4-shell strict |
| Spring Boot uyumu | Çok iyi | İyi (kompleks) | İyi |
| .NET ekosistem | Yaygın | Çok yaygın | Çok yaygın |
| Tipik kullanım sektör | Mikroservis, fintech | Enterprise Java | .NET enterprise |
Sektörel Use Case’ler: Fintech, Enterprise, Mobile Backend
Fintech projelerinde Hexagonal Architecture’ın port-adapter terminolojisi mikroservis mimariye doğal entegre oluyor; ödeme gateway’leri, hesap doğrulama, KYC servisleri her biri portlarla bağlanıyor. Türkiye’de bir fintech projesinde Hexagonal pattern uyguladıktan sonra yeni ödeme provider entegrasyonu süresi 6 haftadan 3 güne indi. Enterprise Java projelerinde Clean Architecture’ın dört katmanlı yaklaşımı yaygın; Spring Boot ile entegre. .NET enterprise projelerinde Onion Architecture default seçim; Domain-Driven Design ile birlikte tasarlanıyor.
Kurumsal Architecture Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Pattern’i terim ezberi olarak uygulamak — dependency rule’a uyulmuyor.
- Repository interface’ini domain’e değil infrastructure’a koymak — pattern violated.
- Application service’in framework annotation’larıyla kirlenmesi — Spring/Hibernate domain’e sızıyor.
- ArchUnit veya benzeri boundary testing aracının kullanılmaması — 3 ayda standart kirlenmesi.
- Use case sınıflarının çok büyük olması — Single Responsibility Principle ihlali.
- Adapter katmanının business logic taşıması — anemic domain anti-pattern.
Sonuç
Hexagonal, Clean ve Onion Architecture aslında aynı felsefenin üç farklı sunumu; hangisini seçtiğinizden çok dependency rule’a disiplinli uyup uymadığınız önemli. Hexagonal pattern terim sezgiselliği ile onboarding’i hızlandırıyor (1-2 hafta vs Clean’in 2-4 haftası). ArchUnit, NetArchTest gibi araçlar pattern uygulamayı terim ezberinden disipline çeviriyor. Spring Boot projeleri için Hexagonal yaklaşımı doğal entegrasyon sunuyor; .NET enterprise için Onion Architecture topluluk standardı. Domain layer her zaman framework-agnostic, application layer framework annotation’larından arınmış, adapter layer framework code. Bir pilot servis üzerinde pattern’i ArchUnit + CI/CD ile uygulayın; başarı kanıtlandıktan sonra diğer servislere yayın. Detaylı kaynak için Alistair Cockburn – Hexagonal, Robert C. Martin Blog ve Jeffrey Palermo – Onion incelenmelidir.
Sıkça Sorulan Sorular
Hexagonal, Clean, Onion arasından hangisini seçmeliyim?
Üçü de aynı dependency rule’a uyuyor; seçim takım onboarding eğrisine ve mevcut framework’a bağlı. Spring Boot ekiplerine Hexagonal (terim sezgiselliği), .NET enterprise ekiplerine Onion (community standardı), Java enterprise ekiplerine Clean (Bob Martin etkisi). En kritik şey terimi değil, dependency rule’u her commit’te ArchUnit ile test etmek.
ArchUnit ile dependency rule nasıl test edilir?
ArchUnit Java için boundary test framework. Örnek: noClasses().that().resideInAPackage(“..domain..”).should().dependOnClassesThat().resideInAPackage(“..infrastructure..”) şeklinde kural yazılır. CI pipeline’da her PR’da çalışır; ihlal varsa build fail. Benzer araçlar: .NET için NetArchTest, Kotlin için Konsist, Go için arch-go.
Hexagonal ile DDD birlikte kullanılır mı?
Mükemmel kombinasyon. DDD strategic patterns (bounded context, ubiquitous language) ile başlanır, tactical patterns (aggregate, repository) Hexagonal’in domain layer’ında uygulanır, port-adapter terminolojisi bounded context’ler arası entegrasyona uygulanır. Vaughn Vernon 2025 ‘Implementing DDD’ güncellemesi bu kombinasyonu eksiksiz örnek olarak veriyor.
Anemic domain model’den nasıl kaçınılır?
Anemic domain (sadece getter/setter olan entity’ler) Clean/Hexagonal pattern’in tipik tuzağı. Business logic’in application service yerine domain entity ve domain service’lerinde yaşaması şart. Order.cancel(), Account.deposit() gibi davranışlar entity üzerinde tanımlanmalı; application service sadece coordinate etmeli, business kararı vermemeli.
Spring Boot annotation’ları domain layer’da kullanılabilir mi?
Hayır. @Service, @Component, @Autowired, @Transactional gibi Spring annotation’ları framework concern; domain layer’da olmamalı. Application service interface’leri domain’de, Spring annotation’lı concrete implementations infrastructure layer’da olmalı. Hibernate annotation’ları (@Entity, @Table) için iki yaklaşım: pure domain + ayrı JPA entity, veya domain entity’de @Entity (pragmatik kabul edilen kompromi).
Ömer ÖNAL
Mayıs 23, 2026Hexagonal, Clean ve Onion Architecture’ın aslında aynı şeyin üç farklı kıyafeti olduğunu söylediğimde itiraz alıyorum ama gerçek bu: hepsi ‘iş kuralları framework’tan, framework iş kurallarından bağımsız olsun’ diyor. Kurumsal müşterilerime önerim, hangi terimi kullandığınızdan çok dependency rule’un her commit’te test edilip edilmediğidir. Pratikte hexagonal terimi takım onboarding’inde daha sezgisel; Clean Architecture ise daha kapsamlı bir kuralname sunuyor. — Ömer Önal