--- title: "Katmanlı Mimari mi, Clean Architecture mı?" description: "Klasik katmanlı yapı çoğu projeye yeterken neden soyutlama katmanlarında boğuluyoruz; Clean Architecture gerçekten ne zaman değer katar?" url: https://sade.dev/tr/journal/katmanli-mimari-mi-clean-architecture-mi/ lang: tr author: "Muhammet Şafak" published: 2026-06-13 updated: 2026-09-06 section: Journal tags: ["architecture","clean-architecture","simplicity","opinion"] summary: "Clean Architecture ile katmanlı mimari doğru ve yanlış cevaplar değil; farklı ağırlıklar ve seçimi domain yapıyor. Çoğu web uygulaması özünde CRUD'dur; orada clean code uğruna Eloquent'e karşı savaşmak kazanılandan pahalıya gelir. Dolaylılık, iş kurallarının framework'ten uzun yaşadığı yerde kendini öder — ve bu ikili bir seçim değil: karmaşık tek bir modül onu taşırken kod tabanının geri kalanı düz kalabilir." --- # Katmanlı Mimari mi, Clean Architecture mı? > Clean Architecture ile katmanlı mimari doğru ve yanlış cevaplar değil; farklı ağırlıklar ve seçimi domain yapıyor. Çoğu web uygulaması özünde CRUD'dur; orada clean code uğruna Eloquent'e karşı savaşmak kazanılandan pahalıya gelir. Dolaylılık, iş kurallarının framework'ten uzun yaşadığı yerde kendini öder — ve bu ikili bir seçim değil: karmaşık tek bir modül onu taşırken kod tabanının geri kalanı düz kalabilir. Bir Laravel projesini ilk açtığımda, tek bir "kullanıcı oluştur" işleminin yedi dosyaya yayıldığını gördüm: Controller, Request DTO, UseCase, Domain Entity, Repository Interface, Eloquent Repository ve iki yönlü bir Mapper. İçindeki tek iş kuralı, e-postanın benzersiz olmasıydı. Bu, Clean Architecture'ın yanlış uygulanmış hâliydi — ama suç Clean Architecture'da değil. Suç, hangi projenin hangi disipline ihtiyacı olduğunu hiç sormamakta. ## İki yaklaşım, kısaca **Katmanlı (layered) mimari** tanıdık olandır: Controller → Service → Repository → veritabanı. Bağımlılıklar yukarıdan aşağı akar, en altta framework durur. Laravel'in kendisi de zaten budur — Eloquent bir active record, controller'lar HTTP'ye bağlı, her şey framework'e gömülü. **Clean Architecture** (ve akrabaları hexagonal, onion) bağımlılık yönünü tersine çevirir: merkezde framework'ten habersiz domain durur, bağımlılıklar **içeri** doğru bakar. Veritabanı, HTTP, framework — hepsi en dıştaki halkada, birer detay. Domain, Laravel'in var olduğunu bilmez. Fark felsefi değil, çok somut: katmanlı mimaride domain Eloquent'e bağımlıdır; Clean'de Eloquent domain'e bağımlıdır. ## Clean Architecture neyi satın alır? Bedava değil, ama gerçek şeyler verir: - **Framework'ten bağımsız test.** Domain kuralları, veritabanı olmadan, saf birim testlerle koşulur. Hızlı; kırılgan değil. - **Framework'ün ömründen uzun domain.** İş kuralları, Laravel sürümlerinden bağımsız yaşar. On yıllık bir domain, üç major framework upgrade'i görebilir. - **Birden çok teslim mekanizması.** Aynı domain'i HTTP API, CLI komutu ve queue worker üzerinden çağırmak doğallaşır. Karşılığında ödediğiniz de somut: her katman geçişinde mapping, daha çok dosya, daha çok dolaylılık. Tek satırlık bir kural için yedi dosya — yazının başındaki manzara. ## Çoğu Laravel projesi için katmanlı yeter Açık konuşayım: çoğu web uygulaması özünde CRUD'dur. Veriyi doğrula, kaydet, oku, göster. Böyle bir uygulamada Eloquent'e karşı "clean code" uğruna savaşmak, kazanılan değerden pahalıdır. Laravel'i bir detay değil, bilinçle seçilmiş bir temel olarak kabul edin. Controller + Form Request + Eloquent model + ince bir service sınıfı — bu, projelerin büyük çoğunluğu için doğru ağırlıktır. Framework'ü kucaklamak bir ödün değil, bir karardır; tıpkı [boring architecture](/tr/journal/neden-boring-architecture) gibi. Yedi dosyalık bir CRUD ise [spekülatif genelliğin](/tr/journal/ileride-lazim-olur-kodunun-faturasi) mimari ölçekteki hâlidir: bugün olmayan bir karmaşıklık için bugünden vergi ödemek. ## Clean Architecture ne zaman karşılığını verir? Disiplin, domain karmaşıklığı yüksek olduğunda gerçek getiri sağlar. Şu sinyaller varsa ciddiye alın: - İş kuralları "kaydet/oku"nun çok ötesinde: çok adımlı hesaplamalar, durum makineleri, sektörel düzenlemeler. - Bu kuralların framework'ten uzun yaşaması bekleniyor. - Aynı domain birden fazla arayüzden besleniyor — API, CLI, mesaj kuyruğu, panel. - Kural değişiklikleri sık ve riskli; veritabanına dokunmadan test edebilmek gerçek bir hız kazandırıyor. Sigorta primlendirme, muhasebe, lojistik optimizasyonu — bu alanlarda Clean Architecture'ın dolaylılığı kendini öder. Bir blog ya da standart bir yönetim panelinde ödemez. ## Hep ya da hiç değil En sık atlanan nokta: bu bir ikili seçim değil. Aynı kod tabanında ikisi bir arada yaşayabilir. Domain'in gerçekten karmaşık olduğu modülü — diyelim fiyatlandırma — Clean tarzı izole edin: saf domain, interface'le ayrılmış repository, framework'ten bağımsız testler. Geri kalan CRUD modüllerini düz bırakın: controller, Eloquent, ince service. [Modüler monolitin](/tr/journal/projelere-neden-moduler-monolit-ile-basliyorum) sağladığı sınırlar bunu doğal kılar — her modül kendi ağırlığını taşır. Mimari, projeye tek tip dağıtılan bir kural değil; karmaşıklığın yoğunlaştığı yere göre ayarlanan bir bütçedir. --- Clean Architecture bir rozet değil, bir araç. Domain'iniz onun çözdüğü problemi yaşıyorsa paha biçilmez; yaşamıyorsa, tek satırlık bir kuralı yedi dosyaya bölen bir törenden ibaret. Mimariyi domain seçer — moda değil. ## Sık sorulanlar **Clean Architecture neyi satın alır?** Domain kurallarını veritabanı olmadan koşan framework'ten bağımsız testleri, framework sürümlerinden bağımsız yaşayan iş kurallarını ve aynı domain'i HTTP API, CLI komutu ve queue worker üzerinden çağırabilmeyi. Karşılığında ödediğiniz de somut: her katman geçişinde mapping, daha çok dosya, daha çok dolaylılık. **Katmanlı mimari ne zaman yeter?** Uygulama özünde CRUD olduğunda: veriyi doğrula, kaydet, oku, göster. Controller artı Form Request artı Eloquent model artı ince bir service sınıfı, projelerin büyük çoğunluğu için doğru ağırlıktır. Yedi dosyalık bir CRUD ise spekülatif genelliğin mimari ölçekteki hâli — bugün olmayan bir karmaşıklık için bugünden ödenen vergi. **Proje geneli için tek bir mimari seçmek zorunda mıyım?** Değilsiniz. Domain'in gerçekten karmaşık olduğu modülü — diyelim fiyatlandırma — Clean tarzı izole edin, geri kalan CRUD modüllerini düz bırakın. Mimari, projeye tek tip dağıtılan bir kural değil; karmaşıklığın yoğunlaştığı yere göre ayarlanan bir bütçedir. ## Kaynaklar - [The Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) — Robert C. Martin - [Hexagonal Architecture (Ports and Adapters)](https://alistair.cockburn.us/hexagonal-architecture/) — Alistair Cockburn