1. GİRİŞ

"Clean Architecture" (Temiz Mimari) yazılım tasarımında sürdürülebilir, test edilebilir ve bağımsız parçalara ayrılmış sistemler inşa etmeye odaklanan bir yaklaşımdır. Uncle Bob (Robert C. Martin) tarafından popülerleştirilen bu paradigm, katmanlı mimariler, bağımlılık yönü ve sınırlar üzerine net kurallar getirir. Modern uygulama geliştirme pratiklerinde — mikroservisler, bulut‑native uygulamalar, mobil backend'ler ve enterprise sistemlerde — mimarinin temiz tutulması uzun vadede bakım maliyetlerini, regresyon riskini ve teknik borcu ciddi şekilde azaltır.

Bu konu neden bugün önemli?

• Servis büyüdükçe kod tabanının karmaşıklığı ve değişim frekansı artar; temiz mimari değişikliklerin izole edilmesine yardımcı olur.
• Test edilebilirlik, CI/CD ve otomasyon gereksinimleri mimarinin parçalanmasını gerektirir.
• Cloud/edge dağıtımları ve çoklu client tipleri (web, mobile, IoT) aynı iş kurallarını kullandığı için bağımlılıkların yönetilmesi kritik hale geldi.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Backend geliştiriciler ve platform mühendisleri
• Projeyi uzun dönem sürdürecek ekipler ve bakım sorumluları

Hangi problemleri çözüyor?

• İş mantığı (domain) bağımsız kalır; UI, altyapı ve framework değişikliklerinden etkilenmez.
• Bağımlılıkların yönetimi kolaylaşır; test ve mock'lama ile birim testleri güvenilir olur.
• Takımların sınırları netleşir; bir bileşen değişirken diğerleri minimum etkiyle devam eder.

2. KAVRAMSAL TEMELLER

2.1 Temel prensipler

• Bağımlılık kuralı (Dependency Rule): İç katmanlar dış katmanlara bağımlı olmamalıdır. Yön, dıştan içe (outer → inner) değil, içten dışa (inner ← outer) doğru olmalıdır.
• Tek Sorumluluk (Single Responsibility): Bir bileşen yalnızca bir sebep için değişmelidir.
• Arayüz‑tabanlı izolasyon: Uygulama dış bağımlılıkları arayüzler (interfaces) üzerinden soyutlanır; implementasyonlar dış katmanlarda yer alır.
• Domain‑centric tasarım: İş kuralları (entities, use‑cases) uygulamanın merkezinde yer alır ve çevresel teknolojilerden bağımsızdır.

2.2 Katmanlar ve terminoloji

• Entities / Domain: İş mantığının temel yapıları ve kuralları.
• Use Cases / Interactors: Uygulama spesifik iş akışları; domain'i kullanarak iş kurallarını uygular.
• Interface Adapters: Controller, Presenter, Gateway gibi katmanlar; dış dünya ile domain arasında çeviri yapar.
• Frameworks & Drivers: Veritabanı, web framework, UI, dış servisler; en dış katmandır ve kolayca değiştirilebilir olmalıdır.

2.3 Bağımlılıkların ters çevrilmesi (Dependency Inversion)

Clean Architecture, dependency inversion principle (DIP) ile yakın ilişkilidir: yüksek seviye modüller düşük seviye modüllere bağlı olmamalıdır; her ikisi de soyutlamalara bağlı olmalıdır. Bu, domain'in altyapı detaylarından bağımsız kalmasını sağlar.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — high level

Clean Architecture tipik olarak içten dışa doğru organize edilmiş katmanları içerir: Domain (entities), Use Cases, Interface Adapters ve Frameworks. Veri akışı genelde şu biçimdedir: bir istek (HTTP, message) Interface Adapter tarafından alınır, uygun Use Case çağrılır, Use Case domain ile etkileşir ve sonuç Interface Adapter aracılığıyla client'a döndürülür. Dış katmanlar domain'e veri gönderirken arayüzlere (port) bağlı olur; port'lar domain tarafından tanımlanır.

3.2 Use Case'lerin rolü

Use Case'ler uygulama mantığını kapsar: bir iş akışı başlatır, gerekli domain nesnelerini işler ve sonuçları koordine eder. Use Case'ler, repository ve gateway gibi abstractions üzerinden veri alıp yazar; Implementasyonlar bu arayüzleri sağlar ve dış katmanda yer alır. Bu yapı Use Case'lerin test edilebilirliğini artırır.

3.3 Interface Adapters ve DTO'lar

Interface Adapter katmanı, dış protokoller ve domain modelleri arasındaki dönüşümü sağlar. Örneğin web controller JSON payload'ı DTO'ya dönüştürür; DTO, Use Case'e iletilir. Benzer şekilde, persistence layer domain nesnelerini veritabanı formatına çevirir. Adapter'lar, dış bağımlılıkların domain'i kirletmesini engeller.

3.4 Bağımlılık yönü ve IOC

Bağımlılıklar içeriden dışa doğru olmalıdır. Bu kuralı uygulamak için Dependency Injection (DI) ve Inversion of Control (IoC) container'ları konfigürasyon seviyesinde kullanılır. Genelde uygulamanın başlangıcında (composition root) arayüzler ile implementasyonlar eşlenir; domain kodu ise bu konfigürasyondan habersiz olur.

3.5 Veri akışı örneği

1. HTTP isteği Controller'a gelir.
2. Controller isteği normalize edip Use Case'i çağırır.
3. Use Case domain servisleri ve entity'lerle etkileşir; repository arayüzünü kullanarak veri okur/yazar.
4. Repository implementasyonu (dış katman) veritabanı ile konuşur.
5. Use Case sonucu Controller'a döner; Presenter/DTO dönüşümü ile client'a cevap verilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix, Uber, Amazon örnekleri

Büyük ölçekli platformlar, farklı ekiplerin bağımsız çalıştığı, hızlı değişimin olduğu ortamlardır. Clean Architecture prensipleri, domain mantığını UI ve altyapıdan izole ederek hızlı değişim gereksinimini karşılamaya yardımcı olur. Örneğin ödeme veya kullanıcı doğrulama gibi kritik domain'ler, altyapı (kuyruk, DB, cache) değişse bile aynı iş kurallarını korur.

4.2 Enterprise uygulamalar

Kurumsal uygulamalarda, birden fazla client (web, mobile, batch) aynı iş kurallarını kullanır. Clean Architecture, ortak Use Case'lerin tekrar kullanılmasını sağlar; adapter'lar her client için ayrı implementasyon sunar. Bu, kod tekrarını azaltır ve test kapsamını genişletir.

4.3 Startuplar ve hızlı evrim

Startuplar için erken aşamada mükemmel mimari yerine çalışır çözümler tercih edilebilir; ancak Clean Architecture prensiplerinin küçük dozlarda erken uygulanması, büyüme döneminde refaktör maliyetini azaltır. Özellikle domain mantığını erken izole etmek ileride hız kazandırır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Test edilebilirlik: Use Case'ler ve domain logic birim testlerle kolayca doğrulanır.
• Değişime dayanıklılık: UI, DB veya framework değişiklikleri domain'i etkilemez.
• Bağımsız deploy ve ekip sınırları: Modüler yapı ekiplerin paralel çalışmasını kolaylaştırır.
• Teknik borcu azaltır: net sorumluluklar ve soyutlamalar kodun anlaşılmasını kolaylaştırır.

Sınırlamalar

• Başlangıç maliyeti: Küçük projelerde aşırı mühendislik olabilir.
• Kuralların yanlış uygulanması: Katmanlar arası kaçaklar (leaky abstractions) oluşursa fayda azalır.
• Operasyonel karmaşıklık: Çok sayıda katman ve arayüz yönetimi ek işler getirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Composition root: uygulama başlangıcında tüm bağımlılık bağlamalarını tek yerde toplayın.
• Arayüz tabanlı testler: dış bağımlılıkları mock'lanabilir arayüzlerle soyutlayın.
• Küçük adımlarla uygulayın: önce domain ve use case izolasyonunu oluşturun, sonra adapter'ları ekleyin.

Performans optimizasyonu

• Profiling yapın; temiz mimari katmanları performans açısından gözden kaçırmayın—örneğin mapping overhead'ini minimize edin.
• Cache stratejilerini adapter seviyesinde uygulayın; domain katmanına cache detaylarını sokmayın.

Güvenlik

• Authentication ve authorization mekanizmalarını interface adapter seviyesinde ele alın; domain sadece yetki bilgisini kullanır.
• Veri validasyonu ve sanitizasyonu iki katmanda yapın: transport‑level ve domain‑level.

Observability

• Use Case çağrı zamanlarını, hata oranlarını ve dış sistem çağrı gecikmelerini izleyin.
• Correlation ID ile dağıtık trace ve log korelasyonu sağlayın.

8. SIK YAPILAN HATALAR

• Arayüzleri domain yerine dış katmanda tanımlamak — bu bağımlılık kuralını ihlal eder.
• Mapping ve DTO'ların kontrolsüz büyümesi — dönüşümlerin merkezi ve test edilebilir olmasına dikkat edin.
• Use Case'lere altyapı sorumluluğu vermek — örneğin transaction yönetimini domain'e sokmak.
• Composition root'u scattering (dağılma) — bağımlılık konfigürasyonlarını tek noktada tutun.

9. GELECEK TRENDLER

1. Tooling ve kod jenerasyonu: Domain modellerinden otomatik arayüz, DTO ve şema üreten araçlar Clean Architecture uygulamasını hızlandıracak.
2. AI destekli refactoring: Large codebase'lerde katman ayrıştırma ve dependency analizini otomatik öneren araçlar yaygınlaşacak.
3. Serverless ve function‑oriented adaptasyon: Clean Architecture prensipleri, fonksiyon bazlı dağıtımlara uyarlanarak küçük, bağımsız use case'ler şeklinde uygulanacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Clean Architecture her projeye uygulanmalı mı?

   Her projede tam uygulama gerekmeyebilir. Küçük, kısa ömürlü projelerde aşırı mühendislik olabilir. Ancak domain izolasyonu, test edilebilirlik ve değişime dayanıklılık gereken projelerde faydası büyüktür.

2. 2. Dependency injection zorunlu mu?

   DI prensipleri Clean Architecture ile uyumludur ve kompozisyonu kolaylaştırır; fakat basit projelerde manuel fabrikasyon (factory) yöntemleri de kullanılabilir.

3. 3. Katmanlar arası performans kaybı olur mu?

   Ek dönüşümler ve soyutlamalar küçük bir maliyet getirir; ancak bu maliyet çoğu durumda yönetilebilir ve getirdiği test‑bakım faydalarıyla telafi edilir. Kritik hot path'lerde profil yapıp optimizasyon uygulayın.

4. 4. Clean Architecture ile CQRS/ES birlikte mi kullanılmalı?

   Clean Architecture, CQRS veya Event Sourcing ile iyi entegre olur; CQRS/ES kullanımı ihtiyaca bağlıdır. Bu kombinasyon daha karmaşık ancak güçlü bir yapı sağlar.

5. 5. Nasıl başlarım?

   Önce domain ve use case'leri tanımlayın; domain kodunu altyapıdan ayırın. Ardından arayüzleri tanımlayıp adapter'ları uygulayın. Küçük iterasyonlarla ilerleyin.

6. 6. Mapping (DTO ↔ domain) nasıl yönetilmeli?

   Mapping fonksiyonlarını test edilebilir utility veya adapter sınıflarında toplayın; otomatik mapping kütüphaneleri (AutoMapper vb.) dikkatle kullanılmalı ve testlerle desteklenmelidir.

7. 7. Monolitik projede nasıl uygularım?

   Monolitik yapı içinde de katmanlaşma ve bağımlılık kurallarını uygulayabilirsiniz. Servis boundary'leri ve paketleme (assembly/module) stratejileri ile modülerlik sağlanır.

8. 8. Hangi metrikleri izlemeliyim?

   Use Case latency, error rate, external call latency, test coverage (domain & use case), CI build times ve deployment success rate gibi metrikler önemlidir.

Anahtar Kavramlar

Use Case

Uygulamaya özgü iş akışı; domain ile etkileşir ve iş kurallarını uygular.

Dependency Rule

Bağımlılıkların iç katmanlardan dış katmanlara doğru olmaması ilkesidir.

Interface Adapter

Dış protokoller ile domain arasında dönüşüm yapan katman.

Composition Root

Uygulama başında bağımlılıkların bağlandığı tek nokta.

DTO

Data Transfer Object; dış katmanlar ve domain arasındaki veri taşıyıcıları.

Öğrenme Yol Haritası

1. 0–1 ay: SOLID prensipleri, DIP ve katmanlı mimari kavramlarını öğrenin; küçük bir demo domain modeli yazın.
2. 1–3 ay: Use Case izolasyonu, arayüz tabanlı repository ve adapter pattern'larını uygulayın; birim testler yazın.
3. 3–6 ay: Büyük kod tabanlarında refactor pratiği (strangler fig), composition root, DI container kullanımı ve entegrasyon testleri deneyin.
4. 6–12 ay: CQRS/ES entegrasyonu, performans tuning, observability ve production‑grade deployment pratiklerini uygulayın.