Clean Architecture her projeye uymaz. Katmanlı yapının gerçekten kazandırdığı yerler ile yalnızca dosya sayısını artırdığı yerleri ayırmanın pratik yolu.
İki zıt cümle, aynı sebep
Clean Architecture hakkında en sık duyduğum iki cümle birbirinin tam zıddı: “her projede kullanıyoruz” ve “gereksiz karmaşıklık”. İlginç olan şu — ikisi de aynı sebepten doğru olabiliyor.
Mimari bir inanç meselesi değil, bir maliyet hesabıdır. Katman eklemek bugün vakit kaybettirir, yarın değişiklik yapmayı ucuzlatır. Asıl soru şu: o yarın gerçekten gelecek mi?
Katman ne zaman kazandırır?
Kendi projelerimde katmanlı yapının kendini ödettiği üç net durum gördüm.
Veri kaynağının değişme ihtimali varsa. Bugün bir veritabanı, yarın kurumun dayattığı başka bir veritabanı. Soyutlama varsa değişiklik tek katmanda kalır; yoksa sorgular projenin her yerine dağılmıştır ve değişiklik projeyi baştan yazmaya dönüşür.
Aynı iş kuralı birden fazla yerden çağrılıyorsa. Bir işlem hem API’den hem zamanlanmış bir görevden hem de içe aktarma ekranından çalışıyorsa, kural tek yerde durmalıdır. Aksi hâlde üç kopyadan biri mutlaka güncellenmeyi unutur.
Projeye başkaları dokunacaksa. Tek kişilik bir projede her şeyin nerede olduğunu bilirsiniz. Üç kişi olduğunda “bu kural nerede” sorusu günde birkaç kez sorulur ve katmanlar bu sorunun cevabı hâline gelir.
Ne zaman yük olur?
| Durum | Neden yük |
|---|---|
| Tek ekranlı iç araç | Katman sayısı kadar dosya, tek bir işlem için |
| Ömrü belli prototip | Yarın silinecek koda bakım kolaylığı yatırımı |
| Sadece CRUD yapan servis | İş kuralı yoksa iş katmanı boş bir geçiş noktasıdır |
| Tek kişilik küçük proje | Ekip iletişimi sorunu yoksa kazanç da yok |
Bu tabloda en çok tartışılan satır üçüncüsü. Yalnızca kayıt ekleyip listeleyen bir serviste, isteği alıp aynen aşağı geçiren bir “servis katmanı” yazmak hiçbir şey kazandırmaz. Boş katman, mimari değil bürokrasidir.
Benim izlediğim orta yol
Projeye tam katmanlı başlamıyorum. Başlangıçta iki şeyi ayırıyorum: iş kuralları ve dışarısı. Bu, klasör açmakla değil bağımlılıkların yönünü korumakla ilgili — iş kuralları veritabanını bilmez.
Sonra bekliyorum. Aynı kural ikinci kez başka bir yerden çağrıldığında, ya da veritabanı sorgusu üçüncü kez farklı bir dosyada belirdiğinde, o zaman soyutlamayı ekliyorum. Bu yaklaşımın avantajı şu: soyutlamayı gerçek ihtiyaca göre tasarlıyorsunuz, tahmine göre değil.
Erken eklenen soyutlamaların çoğu yanlış yerden bölünmüş oluyor; sonradan onları düzeltmek, baştan yazmaktan zor.
Ölçüt olarak kullandığım tek soru
Bir katman eklemeden önce kendime hep aynı soruyu soruyorum: bu katman kaldırılırsa hangi değişiklik zorlaşır?
Cevap somut bir örnekse ekliyorum. “İyi pratik” ya da “herkes böyle yapıyor” cevabı geliyorsa eklemiyorum. Bu tek soru, projelerimdeki gereksiz dosya sayısını gözle görülür biçimde azalttı.
Bu soruyu sormaya başladıktan sonra fark ettiğim bir şey daha oldu: tartışmaların çoğu aslında mimari hakkında değil, ekip alışkanlıkları hakkındaydı. “Katman ekleyelim” diyen kişi çoğu zaman düzen istiyor; “gereksiz” diyen kişi ise hız istiyor. İkisi de haklı olabilir ve mesele hangi ihtiyacın o proje için daha acil olduğuna karar vermekten ibaret.
Bir de şu var: mimari kararlar geri alınabilir olmalı. Katman eklemek, eklemekten vazgeçmekten kolaydır — çünkü kaldırmak, ona bağlanmış her yeri de değiştirmek demek. Bu asimetri yüzünden geç eklemeyi tercih ediyorum. Yanlış zamanda eklenen bir soyutlamayı geri almanın bedeli, biraz geç eklemenin bedelinden yüksek.
Son olarak, bu kararların yazıya geçirilmesi gerektiğini düşünüyorum. Projeye altı ay sonra bakan kişi — ki o kişi çoğu zaman yine sizsiniz — neden repository kullanıldığını değil, neden kullanılmadığını merak eder. Bir sayfalık kısa bir karar notu, aynı tartışmanın her yıl yeniden yapılmasını engelliyor.
Bir konuda da fikrimi zamanla değiştirdim: eskiden mimariyi projenin başında verilecek bir karar sanıyordum. Şimdi bunun bir kerelik karar değil, proje boyunca tekrar edilen küçük kararlar dizisi olduğunu düşünüyorum. Proje büyüdükçe ihtiyaç değişiyor ve baştan verilmiş büyük karar, çoğu zaman yeni ihtiyaca uymuyor.
Pratikte bu şu demek: her yeni özellik, mimariyi yeniden düşünmek için küçük bir fırsat. Kod eklemeden önce “bu, mevcut yapıya sığıyor mu” diye sormak; sığmıyorsa yapıyı zorlamak yerine yapının o kısmını gözden geçirmek. Bu alışkanlık, projeleri büyük yeniden yazımlardan koruyan tek şey oldu benim için.
Daha fazlası: Katmanların hangi sorunu çözdüğünü tek tek gösterdiğim seride bu kararların gerekçelerini bulabilirsiniz.
Videoyu sitemizde izle · YouTube'da aç · Bapati kanalına abone ol