Clean Architecture: Yazılımın Omurgasını Yeniden Keşfetmek
🧱 Clean Architecture: Yazılımın Omurgasını Yeniden Keşfetmek
“Bir mimarinin en büyük amacı, değişime karşı dayanıklı olmaktır.”
— Robert C. Martin (Uncle Bob)
🧭 1️⃣ Giriş: Mimari Nedir, Neden Vardır?
Birçok geliştirici için “mimari” sadece katmanlardan ibaret görünür:
Controller → Service → Repository → Database.
Ama bu bir katman dizisi değildir — bu sadece bir akıştır.
Gerçek anlamda mimari;
- Zamana karşı direnen,
- Teknolojiden bağımsız kalabilen,
- Davranışı (iş mantığını) veriden (altyapıdan) ayıran bir yapıdır.
Yani Clean Architecture’ın amacı:
“Kodun yönünü tersine çevirmek.”
🧩 2️⃣ Tarihsel Gelişim
Clean Architecture bir anda ortaya çıkmadı.
Aslında yazılım mimarisi evriminin ürünüdür.
| Dönem | Mimari Yaklaşım | Temel Fikir | Zayıf Noktası |
|---|---|---|---|
| 1980s | Layered Architecture | UI – Business – Data | Sıkı bağımlılıklar |
| 1990s | N-Tier Architecture | Sunucu katmanları ayrımı | Teknik odaklı, domain kayboldu |
| 2000s | Hexagonal (Ports & Adapters) | Domain merkeze alındı | Uygulaması karmaşık |
| 2010s | Onion Architecture | Domain & Core merkezde | Infrastructure soyutlandı |
| 2012+ | Clean Architecture | Tüm kavramların birleşimi | Öğrenme eğrisi yüksek |
Clean Architecture, Onion ve Hexagonal mimarinin birleşimidir, ama bir adım ötesine geçer:
Yönelim sadece bağımlılıkların yönünü değil, sorumlulukların sınırını da tanımlar.
🧠 3️⃣ Clean Architecture’ın Kalbi: Dependency Rule
“Hiçbir şey, merkezdeki katmanlara bağımlı olamaz.
Bağımlılıklar her zaman içeriye akar.”
Yani:
- Domain (iş mantığı) hiçbir şeye bağlı değildir.
- Application sadece domain arabirimlerini kullanır.
- Infrastructure ve UI bağımlıdır, ama dışta kalır.
Bu yön, zamanla kırılmayan kodun temelidir.
⚙️ 4️⃣ Katmanlar ve Sorumlulukları
| Katman | Açıklama | Örnek Dosyalar |
|---|---|---|
| Entities (Domain) | İş kuralları, saf modeller, aggregate’ler | Order, User, Quiz, ValueObjects |
| Use Cases (Application) | Domain’i kullanan iş senaryoları | CreateOrderHandler, ScheduleQuizCommand |
| Interface Adapters | Use Case’leri dış dünyaya bağlar | Controllers, Presenters, Gateways |
| Frameworks & Drivers (Infrastructure) | Veritabanı, API, Message Broker | EFCoreRepository, RedisScheduler, KafkaBus |
Bu yapı sadece bir dizayn deseni değil —
bağımlılık akışının garantisidir.
🧱 5️⃣ Bağımlılık Kuralları: Gerçek Yönler
Infrastructure → Application → Domain
Presentation → Application → DomainTers bağımlılık prensibi:
- Domain, Application dışındaki hiçbir şeye dokunmaz.
- Application, sadece abstraction kullanır.
- Infrastructure, bu abstraction’ları uygular.
Örnek:
// Application katmanında
public interface IOrderRepository
{
Task SaveAsync(Order order);
Task<Order> GetByIdAsync(Guid id);
}// Infrastructure katmanında
public class EfOrderRepository : IOrderRepository
{
private readonly AppDbContext _context;
public Task SaveAsync(Order order) => _context.Orders.AddAsync(order);
}Domain “OrderRepository”nin var olduğunu bilir, ama nasıl olduğunu bilmez.
Infrastructure ise nasıl kısmını çözer, ama neden kısmını bilmez.
🧩 6️⃣ Clean Architecture ≠ Katmanlı Mimari
Birçok kişi Clean Architecture’ı klasik “3 katmanlı” modelle karıştırır.
Ancak fark katmanların yönünde değil, bağımlılık akışındadır.
| Özellik | 3-Tier | Clean Architecture |
|---|---|---|
| Bağımlılıklar | Yukarıdan aşağı | Dıştan içe |
| Odak | Teknoloji | Domain |
| Test edilebilirlik | Zor | Kolay |
| Değişime direnç | Düşük | Yüksek |
| UI değişimi | Riskli | Kolay |
| DB değişimi | Riskli | Kolay |
🧠 7️⃣ SOLID ve Clean Architecture
Clean Architecture sadece katmanlardan ibaret değildir;
SOLID prensiplerinin mimari seviyedeki yansımasıdır.
| SOLID Prensibi | Mimari Karşılığı |
|---|---|
| S – Single Responsibility | Her katman tek bir amaca hizmet eder |
| O – Open/Closed | Use Case’ler yeni özelliklere açık, değişime kapalı |
| L – Liskov Substitution | Interface Adapters soyutlamaları güvenli |
| I – Interface Segregation | Her modül kendi abstraction’ını kullanır |
| D – Dependency Inversion | Tüm bağımlılıklar Domain/Application’a değil, abstraction’lara yönelir |
🔍 8️⃣ Clean Architecture + DDD = Kusursuz Uyum
Domain Driven Design (DDD), Clean Architecture’ın doğal partneridir.
Çünkü ikisi de “iş mantığı merkezdedir” der.
| DDD Kavramı | Clean Architecture Katmanı |
|---|---|
| Entity / Value Object | Domain |
| Aggregate / Domain Service | Domain |
| Application Service / Command Handler | Application |
| Repository | Interface Adapter / Infrastructure |
| Domain Event | Application / Messaging |
Yani Clean Architecture, DDD’nin teknik kabını oluşturur.
🧩 9️⃣ Clean Architecture’ın Gerçek Hayatta Önemi
1️⃣ Framework bağımlılığını azaltır
Hiçbir iş kuralı Entity Framework veya ASP.NET Core’a bağımlı değildir.
Yarın farklı ORM veya web framework’üne geçebilirsin.
2️⃣ Test edilebilirliği arttırır
Domain + Application katmanları saf C# sınıflarıdır.
Test etmek için veritabanına ihtiyaç yoktur.
3️⃣ Değişime dayanıklıdır
UI’yi Blazor’dan React’a, veritabanını PostgreSQL’den MongoDB’ye çevirebilirsin —
iş mantığın etkilenmez.
4️⃣ Takım ölçeklenebilirliğini kolaylaştırır
Her ekip farklı katman veya modül üzerinde bağımsız çalışabilir.
(Özellikle modüler monolith mimarilerde mükemmel çalışır.)
⚙️ 10️⃣ Clean Architecture ve Infrastructure
Infrastructure “gereklidir” ama “önemsizdir”.
Çünkü teknoloji gelir geçer; iş mantığı kalır.
Infrastructure sadece uygulama için gereklidir, domain için değil.
Örnek:
- EFCore, Redis, Kafka, Elasticsearch, SMTP, HTTP Client, gRPC...
- Tümü Infrastructure’dadır.
- Domain ve Application bu araçları sadece abstraction olarak bilir.
🧱 11️⃣ Clean Architecture’ın Anti-Pattern’leri
| Anti-pattern | Açıklama | Neden Tehlikeli |
|---|---|---|
| Fat Controller | Controller içinde iş mantığı | Presentation sızar |
| Fat Service | Application Service her şeyi yapar | Use Case sınırları bulanık |
| Domain bağımlı EF Core attribute’ları | [Table], [ForeignKey] Domain’de |
Persistence sızması |
| Static helper’lar | Global state yaratır | Test edilemezlik |
| Doğrudan ILogger kullanımı (ör. hot path) | Async pattern kırılır | Performans düşer |
🚀 12️⃣ Clean Architecture’ın Evrimi: Modern Yaklaşımlar
Bugün Clean Architecture artık statik bir model değil,
dinamik bir yaklaşıma dönüşmüş durumda.
| Yaklaşım | Ne ekler |
|---|---|
| CQRS | Command ve Query ayrımı |
| Event Sourcing | Uygulama durumunu event’lerle tutmak |
| Modular Monolith | Domain sınırlarını modüllerle belirlemek |
| Feature Flags / Configurable Pipelines | Davranış değişimini koddan bağımsız hale getirmek |
| Cross-cutting Observability (BufferedLogger) | Performans kaybı olmadan gözlemlenebilirlik |
Clean Architecture artık sadece “katman” değil, bir düşünme biçimi.
🧩 13️⃣ Sonuç: Gerçek Temizlik
Clean Architecture sana şunu öğretir:
“Kodun değil, bağımlılığın temiz olmalı.”
Bir mimari:
- Veritabanı değişse bile sağlam kalıyorsa,
- UI framework’ü değişse bile iş kuralları korunuyorsa,
- Logging stratejisi değiştiğinde bile business logic etkilenmiyorsa,
o zaman gerçekten temizdir.
📚 14️⃣ Özet: Clean Architecture Öz Kimliği
| Alan | Tanım |
|---|---|
| Amaç | Değişime dayanıklı yazılım üretmek |
| Köken | Onion + Hexagonal + DDD birleşimi |
| Prensip | Bağımlılıklar merkeze akar |
| Odak | Domain iş kuralları |
| Yarar | Framework bağımsızlık, test edilebilirlik, uzun ömür |
| Uygulama Alanı | API, Monolith, Microservice, Serverless hepsi |
🔮 15️⃣ Epilog: Clean ≠ Pretty
Clean Architecture, “güzel” kodla ilgili değildir.
“Dayanıklı”, “bağımsız” ve “uzun ömürlü” kodla ilgilidir.
Ve tıpkı iyi bir bina gibi,
güzelliği dıştan değil, taşıyıcı kolonlarından gelir.
“Architecture is about intent and isolation, not about folders.”
— DotNet Senior Developer (C#)
