Clean Architecture kullanarak Node.js Typescript API yazmak

     Merhaba Sevgili Okurlar,

    Bu yazımda yazılım dünyasında önemli bir yere sahip bir uygulama geliştirirken kullandığımız bir arhitectural pattern olan Clean Architecture'den bahsedeceğim.

   Öncelikle Clean Architecture günümüze kadar gelirken ilk olarak aşağıdaki mimarı pattern'lerden evrildi.

• Hexagonal Architecture
• Onion Architecture
• Domain-Driven Design (DDD) or Domain Centric Architecture
• Vertical Slice Architecture
• Clean Architecture

    Bir uygulamayı kodlamadan önce hangi mimariyi seçeceğiniz oldukça önem taşıyor. Projenin ihtiyaçları da en önemli kriterlerden biri. Uygulamayı kaç kişi kullanacak? Müşterinin isteği nedir? Ekibin bilgisi ne düzeyde? Proje deadline'ı nedir? CAP Teoremini göz önünde bulundurmak faydalı olacaktır.

    Projenin bakımı (maintainable), ölçeklenebilir olması (scalable), spagetti code oluşturmaktan kaçınmak, (yeniden kullanılabilir) reusable olmak, kod tekrarından kaçınmak (dublication) soyutlama (abstraction), kodun okunabilir olması (readable) bir projede önemli etkenler. Yazılım dünyası literatüründe olmayan bir yapı ya da herhangi bir mimarisi olmayan projeler geliştiriciler için okunması, anlaşılması zor hale geliyor.

    Öyleyse hadi Clean Architecture'i inceleyelim. Clean Architecture  Robert C. Martin (Uncle Bob)'in ortaya attığı bir yaklaşım. Ana mantık Seperation of Concerns, yazılımı katmanlara bölüp anlaşılabilir parçalara bölmek, birbirleri ile olan bağımlılığı azaltmak.

    Clean Arhitecture aşağıdaki katmanlardan oluşuyor:

• Infrasturcture
• Domain
• Application

Domain Katmanı   

     İlk olarak domain katmanı ile başlayalım. Aynı zamanda örnek bir proje kodları ile de bu yaklaşımı anlamayı destekleyelim. Domain katmanınızda sizin uygulamasını yazdığınız söz konusu modeller yer alır. NSShop uygulaması örnek bir e-ticaret sitesi için bir API olsun. Domaine söz konusu olan modeller Product, Order, OrderDetail, Customer modelleridir.

Customer Modeli:

Domain Services vs Application Services

    Gelelim Domain Services katmanına: Domain Service ve Application Service kavramı oldukça önemli bir konu. Clean Architecture,  DDD (Domain Driven Design) ile oldukça benzer. Uncle Bob'un  Clean architecture'sinde Domain Service gibi bir kavram yok. Application altında Usecase katmanında application'a ait bütün bussiness logic  bulunuyor. Bazı yaklaşımlarda ise Clean Architecture uygulanırken aynı DDD'de olduğu gibi Application ve Domain Service katmanı olarak ayırılıyor. Domain Service'de Domain'e ait bussiness rule'ları olurken Application'da ise tüm ugulamayı ilgilendiren Application rule'ları oluyor. Bu konuyu en güzel anlatan örneği şu yazıda bulabilirsiniz.

Business logic'inizi ya tamamen UseCase katmanında toplarsınız ya da Domain ve Application Service olarak ayırırsınız ikisi de doğru ikisi de Clean Architecture yaklaşımına aykırı değil. Ben bu örnekte Application Service ve Domain Service olmak üzere iki ayrı katmanda tutuyorum. DDD'ye baktığımızda Clean Architecture'ye göre domaini modellemenin daha ön planda olduğunu görüyoruz. Önümüzü Value Object, Aggregate, Bounded Context gibi kavramlar giriyor. Bu kavramlar Clean Architecture'de yok. DDD ve Clean architecture karşılaştırması için şu yazıyı okuyabilirsiniz.

Domain Services Katmanı

    Şimdi tekrar Domain Service'ye geri dönelim

Domain Service her bir domain'e ait domain logic'lerimizi barındırdığımız yer:

Infrasturcture Katmanı

    Infrasturcture katmanı ise database, repository, file system ile ilgili class'laırmızın olduğu ya da 3rdparty entegresyonlarımızı (webservice), message bus, configurasyon, logging,  yaptığımız katmandır. Diğer katmanları inşa edebilmemiz için temel bir katman gibi düşünebiliriz.

Application Katmanı

    Son olarak Application katmanını inceleyelim. Application katmanı domain'in uygulandığı proje için gerekli useCase'lerin implemente edildiği katmandır. Domain modelleri ve DTO'lar da bu katmanda map edilir. Bu katmanda eğer bir API yazıyorsak Controllar'lar, ViewModels ya da DTO'lar, Mappers, Validators, Application Exceptions, Application Logic, Eğer CQRS kullanıyorsak Command/Queries'i barındıran katmandır.

Ben örnek projemde Application Logic'i ayrı bir katman olarak yazdım. 

Daha önce bahsettiğim gibi Application ve Domain Logic'lerini ayırmayıp hepsini Application katmanına ait olan UseCases içinde barındırabilirsiniz. DDD yaklaşımında ise kesinlikle ikisinin birbirinden ayrılması doğru.

    Böylece bütün katmanları açıklamış olduk. Ben ve ekibim bütün projelerimizde bazen DDD bazen Clean Architecute uyguluyoruz. Ekip üyeleri cross-functional çalışabiliyor, geliştiriciler kodu daha iyi anlıyor ve code review'lerde kolaylık sağlıyor, en önemlisi projeyi devralan geliştirici karmaşa olmadan yoluna devam ediyor, kod karmaşıklığından kurtulmuş oluyoruz. Standartlar hayat kurtarıcı olabiliyor.

    Projeyi çalıştırdığımızda aşağıdaki Swagger ekranı geliyor ve bu ekranda API'ı kolayca deneyebilirsiniz.

    DDD ile ilgili olan yazımı da yakında sizlerle buradan paylaşacağım. Aşağıda faydalı kaynakları sizlerle paylaşıyorum:

Clean Architecture

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://www.dandoescode.com/blog/clean-architecture-an-introduction

Domain Driven Design

https://github.com/heynickc/awesome-ddd

https://copyprogramming.com/howto/where-to-put-business-logic-in-ddd

Bussiness Logic vs Application Logic

https://jonascleveland.com/difference-of-business-logic-vs-application-logic/

https://docs.abp.io/en/abp/latest/Domain-Services

Domain Driven Design vs Clean-architecture

https://khalilstemmler.com/articles/software-design-architecture/domain-driven-design-vs-clean-architecture/

     Umarım faydalı olmuştur, örnek projeyi github repomda bulabilirsiniz bir sonraki yazıda görüşmek üzere.

Sağlıkla kalın.