Clean Architecture (Temiz Mimari) Nedir ?
Merhabalar, yazılımlar doğası gereği sürekli değişen ürünler olduğu için değişime açık olmalılar bunun için de yıllarca biriken tecrübelerle paradigmalar, mimariler, tasarımlar ve yaklaşımlar geliştirmiştir yazılımcılar.
Uncle Bob’a göre düzgün çalışan ve yeni isteklere, gereksinimlere cevap veremeyen bir uygulama; düzgün çalışmayan ama yeni isteklere cevap verebilen ve değiştirilmesi kolay bir uygulamadan daha tercih edilebilir bir durumdur.
Tabiki de yazılımın amacı çalışan ürünler çıkarmaktır. Eğer isteklere cevap verebilen ve değişimi daha az efor isteyen bir uygulamanız var ise bir sorun çıktığı zaman bunu düzeltmeniz daha kolay olacaktır. Ancak eğer bir uygulama değişime karşı dirençli olursa ve değişimler çok efor istiyorsa artık ihtiyaçları karşılayamayan başarısız bir uygulama olma yolunda ilerleyecektir.
Yazılım Mimarisi Nedir ?
Yazılım mimarisi, bilginin bir yazılım sisteminde nasıl ilerlediğini belirleyen yapıdır. Yazılımın amacına ulaşması için nasıl organize edileceğini, ve hangi sırayla çalışacağını belirler. Bir yazılım projesinin farklı yerlerinde farklı mimariler yaklaşımlar uygulayabilirsiniz tekil olmak zorunda değildir.
Mimarinin temel amacı minimum efor, maksimum üretkenliktir. Bu sayede ihtiyaçları daha kısa sürede giderebiliriz. Bir yazılım mimarisinin kalitesini de bu belirler.
Bir çok yazılım mimarisi bulunmaktadır ve her biri detaylıca anlatılacak konulardır o yüzden bu yazımda Clean Architecture’dan bahsedeceğim.
Clean Architecture Nedir ?
Clean architecture, uygulamamızın bağımlıklarının tek yönlü ve içe doğru olmasını savunan bir yazılım mimarisidir.
Bu mimaride yazılım belirli katmanlara ayrılmıştır bunlar Domain, Application, Infrastructure ve Presentation‘dır.
Görselde görüldüğü üzere oklar(bağımlılıkların yönünü temsil eder) içe doğrudur. Şimdi bu katmanlar üzerinde biraz konuşalım.
Domain: Bu katman bizim çekirdek katmanımızdır. Bu katman diğer hiçbir katmana bağımlı değildir. Bu katmanda business entitylerimiz olur bunlar genelde basit ve küçük sınıflar olur. Ayrıca Value Objects, Logic, Exceptions ve Enemurationlarımız da bu katmanda yer alır.
Application: Application katmanı sadece Domain katmanına bağımlıdır ve oradaki bileşenleri kullanarak business logic’i oluşturur. Bu iki katman ile uygulamamızı oluştururuz. Bu katmanda verileri nasıl saklıyacağımızın, client ile nasıl iletişime geçeceği gibi konuları soyut bir şekilde oluşturup diğer üst katmanlarda bunları gerekiyorsa implemente edip kullanırız. O yüzden bu katmanda Interface, Model, Logic, Command/Queries, Validators/ Exceptions’ larımız bulunabilir.
Infrastructure: Bu katmanda application katmanında ki Interfaceleri implemente ederek veritabanı gibi operasyonların implementasyonlarını yaparız. Projemizin hiçbir katmanı bu katmana bağımlı değildir.
Presentation: Bu katman kullanıcının uygulama ile iletişime geçtiği katmandır. Bu katman da konsol, api ve ya mvc projesi olabilir. Bu katman en üst katmanlardan biridir bu yüzden hiç bir katman bu katmana bağımlı değildir.
Neden Clean Architecture ?
Sık kullanılan MVC mimarisine nazaran O.A hem seperation of concerns hem de tightly coupling sorununu çözüyor.
Bütün katmanlar çekirdeğe bağımlı olduğu için maintain etmesi daha kolay. Katmanlar arası ilişkinin soyut sınıflarla yapılmasıyla loosely coupled ve test edilmesi kolay bileşenlerimiz oluyor.
Teorik bilgisini verdiğim bu konunun üzerine bir de kısa bir pratik yapmak istiyorum. Şu günlerde öğrenmeye başladığım ASP.NET dünyasından bir örnek uygulama yapacağım. Haydi biraz kod görelim.
Proje Yapısı:
Projede ürünlerimiz olacak, bu ürünleri kalıcı olarak tutmak için MySQL kullanacağız ve kullanıcıların uygulamayı kullanması için bir api oluşturacağız.
Öncelikle bir solution oluşturup bunun altında 4 ayrı proje oluşturuyoruz. Core katmanı için Application ve Domain adında dotnetstandart classlib türünde 2 proje oluşturuyoruz. Infrastructure altında bir dotnetcore clasllib oluşturuyoruz. Ve son olarak Presentation altında bir webapi projesi oluşturuyoruz.
Domain Katmanı Implementasyonları:
Entity’lerin çoğunda Id property si bulunur bunun için ortak kullanılabilecek bir soyut sınıf oluşturuyorum. Daha sonra Product sınıfımı bundan türetip sınıfa ait property leri tanımlıyorum.
Application Katmanı Implementasyonu:
Uygulamamızın ürün listeleme, ürün ekleme gibi feature ları var bunları burada implemente ediceğiz.
IApplicationContext.cs
Bu interface bizim ürünlerimizin kalıcı olarak saklanması, getirilmesi gibi işlemleri yapacak olan sınıflar için bir sözleşmedir bunun implementasyonu Infrastructure katmanında yapılacaktır. Bunu bir interface yaparak Application ve Infrastructure katmanı arasındaki bağımlılığı azaltıyorum.
Ürün Listeleme Feature:
Burada ki yapımızı diğer feature larımızda da kullanacağız. Uygulamamıza bu handler sınıflar ile isteklerini bildirecekler eğer gerekiyorsa parametre olarakta bu işin yapılması için gereken değerleri yine query ve ya command sınıflarımızla iletecekler. Gördüğünüz gibi veritabanı için ApplicationContext’in interface ini constructor ile alıyoruz bunu dependency injection ile webapi bizim yerimize sınıflarımıza geçirecektir. Diğer feature larımızda da aynı yolu izleyeceğiz.
Ürün Ekleme Feature:
Burada görüldüğü üzere ürün ekleme işlemi yapabilmek için Name, Barcode, Description ve Rate gibi property leri vermesi gerektiğini söylüyoruz.
Şimdi uygulamazın veritabanı ile nasıl iletişim kuracağını implemente ediceğiz Infrastructure katmanında.
Infrastructure Katmanı:
Entity framework bizim için işin çoğunu yaptığı için bize fazla iş düşmedi.
Domain, Application ve Infrastructure katmanlarımız hazır şimdide webapi mizi hazırlayalım.
Presentation Layer
Bu layerda apimizde ürünler üzerinde işlem yapmak için ProductController’ı oluşturalım.
Kullanıcılar için endpointlerimizi hazırladık şimdi bunları postman ile deniyelim.
Post İşlemi:
Get İşlemi:
Evet gördüğünüz üzere uygulamıza ürün ekleyip listeleyebiliyoruz. Uygulamamızın feature larını başarılı bir şekilde implemente edebildik.Yazının çok uzamaması ve ana konusundan sapmaması için konfigurasyon detaylarını atlatarak clean architecture u ilgilendiren kısımları göstermeye çalıştım.
Bu mimarinin sağladığı avantajlardan biri de kolay test edilebilmesi. Bir kaç test yazalım.
Testing
Projede EF Core kullandım bunun içinde asp.net sayfasında biraz gezince sqllite in memory ile testleri yazmaya karar verdim. Bu sayfada detaylı bilgiye ulaşabilirsiniz.
Öncelikle IApplicationContext için bir somut implementasyon yazıcağız daha sonra da bize sqllite in memory konfigürasyonu ile context’i oluşturacak factory sınıfını yazıp testlerimizde burdan üreteceğiz contextimizi.
Factory ve ApplicationContext sınıflarımızı oluşturduk şimdi de testlerimizi yazalım.
Testlerimizin izole, bağımsız çalışması için her testin ayrı contexte sahip olması lazım context oluşturacak bir metod yazdım, testlerde de bu metodu kullanarak contexti alıyorum.
Son
Evet testlerimizi de yazdıkdan sonra yazının sonuna geldik. Clean Architecture hakkında bir fikir verebildiysem ne mutlu bana. Eleştirilerinizi ve yorumlarınızı bekliyorum siz bu mimari hakkında neler düşünüyorsunuz ve sizce başarılı bir mimari midir ?
