Clean Architecture Nedir?
Clean Architecture nedir? Neden kullanmalıyız? Avantajları nelerdir?
Bu yazımda 7 aydır üzerinde çalıştığım erteleye erteleye bugün yazmaya fırsat bulduğum Clean Architecture konusunu açıklamaya çalışacağım. Mimariyle alakalı projeye yazının sonundaki linkten ulaşabilirsiniz.
Ön Bilgi
Bu mimarinin yaratıcısı olarak “Uncle Bob” adıyla tanınan Robert C. Martin’dir. Ben yazımda ise Jason Taylor’un geliştirdiği biraz daha farklı, gelişmiş versiyonunu anlatacağım. Ben ana kaynaklardan da incelemek isterim derseniz buradan ulaşabilirsiniz.
Avantajları
- Framework bağımsız
- Test edilebilir
- Arayüz bağımsız
- Veritabanı bağımsız
Hexogonal ve Onion mimarileri ile ayrıntılarında biraz farklılık gösterseler de, birbirlerine çok benziyorlar. Çünkü bu mimariler temelde aynı amaca hizmet eder yani işlerimiz katmanlara ayırmamıza.
Katmanlara neden ayırmalıyız ?
Bu sorunun birden çok yanıtı var aslında. Öncelikle sistemimizin iş parçacıklarının birbirinden ayrı, herhangi bir değişiklikte diğer parçaları da değiştirmeyecek bir yapıda olmasını isteriz. Tabi bu tek sebep değil projenin boyutu arttıkça okunulabilir olması da çok önemlidir. İş parçacıklarını gerçekten birbirinden bağımsız yada bir diğer adıyla gevşek bağlılık(loose-coupling) yapmış isek kolayca test yazabilir ve sonradan yapılan değişikliklerde sistemimizde herhangi bir sıkıntı olup olmadığını gözlemleyebiliriz.
Katmanlar 📚
Aşağıdan da görebileceğiniz gibi katmanlarımız iç içe daireler şeklinde ilerliyor. Her bir daire sadece bir içteki daireye ihtiyaç duyar. Mesela Application katmanın bağımlılığı sadece Domain katmanıdır.
İç daireden başlayarak dışarıya doğru adım adım açıklayarak ilerleyelim.
Domain Katmanı 💡
Domain katmanında projenin kesinlikle ihtiyaç duyacağı olmazsa olmazlarımızdan olan elemanlarımız olacak bunlar nedir ?
Entities
ORM araçlarının gelişmesiyle beraber proje içinde oluşturduğumuz sınıflar ile veritabanı oluşturabilmemiz bu katmanda çok işimize yarıyor.
Yazım ASP.Net üzerine olduğu için burada küçük bir not bırakmak istiyorum. Veritabanı nesnelerinizi oluştururken Fluent API kullanmamız gerekiyor.
Value Object
Kendine ait eşsiz bir kimliği olan nesneler Entity olarak adlandırılırken, kendine ait bir kimliği olmayanlar ise value object olarak adlandırılır. Immutable ve mutable kavramındaki mutable: Entity ve immutable: Value Object olarak düşünebiliriz.
Logic
Gerçekten domain ilgilendiren mantıksal işlemlerimiz
Exceptions
Domain için oluşturduğumuz exception sınıflarının da bu katmanda olması gerekiyor.
Burada asıl önemli olan belki de en çok kullanılan en azından benim kullandığım kısım Entities kısmıdır. Diğerleri çok daha kompleks işlerde kullanılabilir.
Application Katmanı 🈸
Gelelim Application katmanına, burası bizim genel olarak mantıksal işlemlerimizi yaptığımız katmandır. Örnek olarak gelen isteklerin işlendiği validasyonlarının yapıldığı veritabanı kayıtlarının yapıldığı katmandır. Kafanızda tam oturtturamamış olabilirsiniz ama sorun değil detaylı bir şekilde proje üzerinde göreceğiz. Bu katmanın tek bağlılığı domain katmanı olmalıdır.
Interfaces
Mail servisi veya notification arayüzleri olabilir.
Models
Application katmanında kullanacağınız modeller olabilir.
Logic Commands / Queries
Burası önemli servise gelen isteklerin Request ve Response modellerini, bu servislerin mantıksal işlemlerini ve veritabanı kayıtlarının bulunduğu kısım.
Validators
Gelen isteklerin validasyonları bulunur.
Exceptions
Oluşan hatalar için de kişiselleştirdiğimiz Exception sınıflarımız bulunur.
…
Gelen isteklerin bir okuma işlemi mi yoksa yazma işlemi mi durumlarına göre farklı modeller ve farklı metotlar ile işlemlerimizi yaparız. Kısacası okunabilir, düzenlenebilir ve test edilebilir bir yapı sunar. Bu tasarım kalıbı(CQRS) hakkında daha detaylı bilgi için Microsoft Docs içinde güzel bir yazı var buradan ulaşabilirsiniz. Uygulama içi mesajlaşma için ise MediatR, validasyon işlemleri için ise FluentValidation paketini kullanacağız.
Persistence Katmanı 🎫
Bu katman genel olarak DbContext işlemleriyle alakalıdır. Migrationların yönetimi, veritabanı tablolarının configleri için oluşturulmuş Fluent API sınıfları ve default veritabanı değerleri. DbContext bu katmanda olmasına rağmen hala veritabanı bağımlılığımız yoktur. ConnectionString AppSettings içinden erişilecek.
DbContext
Migrations
Configurations
Seeding
Infrastructure Katmanı ➕
Bu katmanda ise sisteme eklenecek external şeyler bulunur. Bu katmana hiçbir katmanın bağlılığı olmamalıdır.
Email / SMS
System Clock
Notification
Presentation Katmanı 🎆
Bu katmanda isminden anlaşılacağa üzere sunum katmanı. Ben Web API projesinde çalıştım. Bu katmanda mantıksal işlemler olmamalıdır. O iş Application katmanında olmalıdır.
SPA - Angular veya React
Web API
MVC
Web Forms
“Ben teoriden anlamam varsa proje göster koçum!” diyenler için
Benimde referans aldığım projeye aşağıdaki linkten göz atabilirsiniz. Açıklama kısmında video ve slayta da ulaşabilirsiniz.
Yazımın burada sonuna geliyorum. Umarım kafanızda bir şeyler canlandırabilmişimdir. Herhangi bir sorunuz olursa bana buradan(Linkedin) üzerinden ulaşabilirsiniz.
