Temiz Mimari (Clean Architecture) ilgilerin ayrımı (seperation of concerns) prensibi baz alınarak, ortaya atılmış ve günümüzdeki modern yazılımların bir çoğunda kullanılmaya başlanan, modüler bir yazılım geliştirme mimarisidir. Uncle Bob (Robert C. Martin) tarafından ortaya atılan mimari aşağıdaki özellikler üzerine kurgulanmıştır.

1. Uygulama yeni isteklere kolay adapte olabilmelidir

2. Katmanlar arasında bağımsız (loose-coupled) bir ilişki olmalıdır.

3. Uygulama kolay test edilebilir olmalıdır.

4. Uygulamanın 3rd parti bağımlıkları olmamalıdır.

5. Her bir katmanın sınırları (boundaries) belirgin olmalıdır.

Presentation Layer:

Son kullanıcıdan (end user) gelen istekleri ilk karşılayan katmanımızdır. Kullanıcının uygulama ile etkileşimi sonucunda, uygulamaya bir iş istediği (use-case) gelmektedir. Bu katmanın görevi gelen bu iş istediğini işlemek (handle) değil ilgili alt katmanlara yönlendirilmesini sağlamaktadır. Yani bu katman işin nasıl işleneceği ile ilgilenmez, işin ilgili iş birimine aktarılmasından sorumludur. Bu katman teknoloji bağımlılığının en üst düzey olduğu bir katman olmak ile birlikte, bir çok yazılım dilinde farklı teknoloji altyapıları ile geliştirilmiş bir uygulama (application) olabilir. Bu katmanda web uygulaması, desktop uygulaması veya mobil uygulama konumlandırılmaktadır.

Şimdi bu katmanları inceleyelim.

Persistence Layer

Bu katman ise verinin kalıcılığı (persistence) ile ilgilenen bir katmandır. Uygulama içerisindeki verinin bir dosyaya yazılması veya bir veri tabanında (database) tutulması bu katmanın sorumluluğudur. Buradaki temel nokta verinin bellekte (ram) değil kalıcı bir çözümde (disk,storage) saklanmasıdır. Tahmin edersiniz ki verilerimizi ihtiyacımıza göre bir çok farklı teknoloji altyapısı ile saklamamız gerekebilir. Bu katmanda farklı teknolojilere ait veri erişim (Data Access) implementasyonları tercih edebilirsiniz. (EF Core, NHibernate, Dapper, Hibernate, Type ORM, Ado.Net, Mongo Driver). Verilerinizi ihtiyacınıza göre ilişkisel olmayan (nosql) veya ilişkisel (sql) olarak tablolarda saklayabilirsiniz. Tabi ki bu katman sadece verinin veritabanında saklanması ile ilgilenmiyor. Aynı zamanda bir verinin farklı dosya formatlarında (xml, json, docx, xlsx, csv) saklanması ile ilgili çözümlerde bu katmanın sorumluluğundadır.

Bu katmanda yapmamız gereken en önemli şey, uygulamanın veri katmanındaki bu teknolojilere bağımlı kalmaksızın zayıf bağlı (loose-coupled) bir şekilde haberleşmelerinin sağlanmasıdır. Bu katmanda Repository tasarım deseni uygulanarak bu sorunu ortadan kaldırabiliriz. Katmanlar arası bu bağımlılıklardan nasıl kurtulacağımıza dair yöntemleri ise farklı bir makalede ele alacağım.

Infrastructure Layer

Bu katman uygulama içerisinde kullanılan 3rd servislerin uygulamaya adapte edilmesi ile ilgilenen bir katmandır. Uygulamanın On-Premise veya On-Cloud farklı altyapılar ile çalışabilmesi bu katmanın sorumluluğu altındadır. Bu katmanda (service bus communication, notification management, storage management, 3rd api web services, serverless services, instantly messaging, realtime-communication) ve daha fazla çözümü uygulamasınıza entegre edebilirsiniz. Aşağıda sektörde yaygın olarak kullanılan bir kaç 3rd servislere ait örnekler, Infrastructure katmanının sorumluluğunu anlamanız açısından daha açıklayıcı olacaktır.

1. Uygulamanın email altyapısı için kullanılan 3rd servisler (SendGrid)

2. Uygulamda sms altyapısı için kullanılan 3rd servisler (Twilio SMS)

3. Uygulamada bildirim altyapısı için kullanılan 3rd servisler (OneSignal)

4. Mikro hizmetlerin birbirleri asenkron haberleşme altyapısı (Azure Service Bus, RabbitMq, Kafka)

5. Uygulama içerisindeki verilerin ön bellekte (cache) tutulması. (Redis, AWS ElasticCache)

6. Uygulamadaki işlemlerin loglanması ve raporlanması (ElasticSearch)

Application Layer

Bu katmanın görevi son kullanıcıdan gelen iş isteklerini bir arayüz altında toplayarak, işin koordinasyonunu sağlamaktadır. Bu özelliği sayesinde aslında tasarım desenlerinden Facade Design Pattern mantığı ile geliştirilir. Sektörde edindiğim tecrübelere istinaden ülkemizde en az kullanılan katman olduğunu görmekteyim. Bir çok şirket bu katmanı oluşturmanın uzun vadede getireceği yararları göz ardı ederek, işin hızlı bir şekilde çıkmasına odaklanıyor. Ve durum böyle olunca aslında bir çok Migration (teknoloji geçişleri veya üst versiyon geçişleri) hüsran ile sonuçlanıyor. Bu katmanın yazılmasındaki temel sebep, Presentation katmanında gerçekleşmesi muhtemel bir teknoloji değişimi veya bir versiyon güncellemesine (Migration) uygulamanın çevik bir şekilde adapte olabilme becerisinin kazandırılmasıdır. Bu katmanın yazımı kullanım durumlarını (use-case) Application Layer da toplayacağı için, Presentation Layer da sadece gelen iş isteğinin bu katmana yönlendirilmesi ile ilgili servisler tüketilecektir. Bu katmanda CQRS (Command Query Seggragetion Principle) uygun bir geliştirme yapılması modern yazılım uygulamalarında popüler hale gelmiştir. CQRS prensibine farklı makalelerim de yer vereceğim. Fakat CQRS prensibi kullanılmadan da SOLID Prensipleri uygulanarak Application Layer da görev bazlı (task-based) geliştirmelere yer verilebilir. Bu katmanda (Validations, Mappers, Queries, Commands, Handler, Integration Events, Data Transfer Objects, Application Services) gibi kavramlar barındırılır.

Domain Layer

Uygulamadaki nesnelerin (Domain Model-Entity) bulunduğu, uygulamanın iş kurallarının (bussiness logic) geliştirildiği katmandır. Bu katmanda uygulamanın iş süreçleri (Domain) ve bu iş süreçlerine ait iş kuralları (bussiness cases) ve iş akışları (bussiness flows) bulunur. Uygulamanın ölçeğine göre tek bir domain altında geliştirileceği gibi, büyük ölçekli (large-scale) uygulamalarda, Core Domain (çekirdek isim alanı) altında birden fazla Sub-Domain (Alt isim alanı)’ dan meydana gelecek şekilde geliştirilebilir. Her domain kendi bağlamlarındaki (Bounded Context) iş kurallarını uygulamak ile sorumlu tutularak ve sadece kendi domain’e odaklanmalıdır.

Aşağıdaki özellikler göz önünde bulundurularak geliştirme yapılmalıdır.

1. Uygulamadaki en değerli, önemli katman Domain Layer’dır.

2. Domain layer diğer hiç bir katman ile bağımlı olmamalı ve teknolojik kaygılar içermemelidir.

3. Bu katmanda (Entities, Value Objects, Domain Events, Domain Handlers, Aggregate Roots, Domain Services) gibi kavramlar barınır.

4. Bu katman istisnai olarak sadece Core Layer adını verdiğimiz Cross-Cutting bir katmandan beslenebilir (referans alabilir).

5. Diğer tüm katmanlar bu katmandan referans alabilir.

Evet yukarıda teknik anlamda Clean Architecture (Temiz Mimari) üzerine konuştuk, birçok kavramı sektörde edindiğim tecrübelere istinaden açıklamaya çalıştım. Bir sonraki makalem de örnek bir kod akışı üzerinden ilgili katmanların birbirleri ile iletişimini gerçek hayat senaryoları üzerinden göstereceğim bir örneğe yer vereceğim.

Sürdürülebilir, test edilebilir, ölçeklendirilebilir ve daha anlaşılır (clean-code) geliştirmeler yapmanız dileğiyle…