Vertical Slice Architecture Nedir?

Robert C. Martin’e göre temiz bir mimarinin iki temel özelliği vardır:
Loosely coupling ve Separation of Concerns.

Loosely coupling’e göre nesnelerin arasındaki ilişkilerin minimum düzeyde bağlılık içermesi gerekir.

Örneğin, bugün database olarak MSSQL kullanıyoruz diyelim, maliyetler arttı ve bir anda PostgreSQL’e geçme kararı aldık. Bu durumda uygulamamızı fazla kod değişikliği yapmadan PostgreSQL’e geçirebilmemiz gerekiyor.

Separation of Concerns’e göre ise; her metod ve sınıfın kendine ait görevi olmalıdır ve bu görev tanımlarının dışına çıkmamalıdır.

Tüm bu bilgiler ışığında bugüne kadar öğrenmiş olduğumuz Clean Architecture Mimarisine bir göz atalım, sonrasında Vertical Slice Architecture felsefesine giriş yapalım ve farkları birlikte inceleyelim.

1. Clean Architecture

Clean Architecture mimarisine en uygun örnek olarak Onion Architecture yapısını inceleyelim.

Orion Architecture yapısı gereği bir bütündür ve her katmanın sadece bir içteki katmana bağlılık göstermesinden dolayı soğan şekline benzetilmiştir.

Bu sebeple merkezi katmanlar, bir dışındaki katmana bağlılık göstermez bu da bize Loosely coupling’i sağlamaktadır. Aynı zamanda sorumluluğuna göre projeyi katmanlara ayırması da bize Separation of Concerns’i sağlar.

Peki gerçekten de öyle mi?

Onion Architecture Sorunları

Bu tarz mimarilerde katmanlar birbirine (Tightly Coupled) sıkı bağlıdır ve kendi içinde katı kurallara sahiptir. Bu da uygulamayı maintain etmede zorluklar yaşatır.

Alt katmanda yapılan bir geliştirme tüm üst katmanları etkileyebilir. Örneğin Repository’de bir değişiklik yaptığınızı düşünün, bu değişiklikten Repository’i çağıran tüm servis ve metodlar etkilenecektir. Aynı şekilde yazdığınız unit ve integration testler de bu değişiklikten nasibini alacaktır.
Uygulama büyüdükçe de complexity artacak, bugları fixlemek, yeni feature’lar geliştirmek, geliştirilen feature’ları anlamak ve bunlara test yazmak oldukça zorlaşacaktır.

Yani aslında her ne kadar Loosely Coupled gibi görünse de doğası gereği monolith’e evrilebilen bir yapıya sahip.

Peki bu durumu Vertical Slice Architecture nasıl çözüyor?

Vertical Slice Architecture Mimarisine Giriş

Her bir Slice için bu makalede Dikey Blok ifadesini kullanacağız

Bu mimari ilk defa, Mediatr’ın da geliştiricisi Jimmy Bogard tarafından ortaya atılmıştır. Jimmy Bogard’ın Vertical Slice Architecture ile ilgili makalesini buraya bırakıyorum.

Vertical Slice Architecture kısaca; uygulamayı yatay katmanlar olarak değil, dikey feature blokları olarak böl der ve her bloğun kendi içinde UI, Application, Domain ve DB logicleri vardır.

Örneğin; bir e-ticaret uygulaması geliştiriyorsunuz diyelim. Uygulamada Product modülünü microservice yapmaya karar verdiniz. Clean Architecture mimarisinde katmanlarınız aşağıdaki gibi olacaktır.

ProductEntity -> Product
ProductRepository -> Create, Get, Update, Delete
ProductService-> CreateProduct, GetProducts, UpdateProduct, DeleteProduct
ProductUI-> CreateProductUI, GetProductUI, UpdateProductUI, DeleteProductUI

Bu durumda Product ile ilgili yeni bir feature eklemek istediğinizde bir çok katmana dokunmanız gerekecek.

Vertical Slice Architecture ise Create, Get, Update ve Delete feature’larını birbirinden izole dikey bloklar içerisine, her bloğa bir feature gelecek şekilde yerleştiriyor. Her süreç kendi bloğu içinde diğerinden habersiz ilerliyor. Create feature’ında yapılacak bir geliştirme sadece o blokta gerçekleştiği için Delete feature’nın bundan haberi olmuyor. Ya da yeni bir feature eklemek istediğimizde diğer bloklara dokunmadan yeni bir dikey blok oluşturabiliyorsunuz.

Her dikey blok sadece kendi business sürecini işlettiği için IRepository ve IService gibi abstract katmanlara da gerek kalmıyor. Süreçler, blokların içerisindeki Command ve Query’lerde yönetiliyor.

Böylece bloklar arasındaki coupling minimum’a inerken, bir bloğun içerisindeki coupling maksimuma çıkıyor.

Ayrıca her dikey blok içinde kullanılan teknoloji diğer bloktan farklı olabiliyor. Bir blokta Dapper kullanırken, diğer blokta EntityFramework kullanabilirsiniz, bir başka blokta ise Stored Procedure.
Tamamen özgürsünüz!

Avantajları

1. Bir feature’da yapılan değişiklik, diğer feature’ları etkilemiyor.
2. Bir hatada, hatayı aramak için sadece ilgili feature’a bakmak yeterli. Bu durum da hatayı bulma ve çözme süresini kısaltıyor.
3. Unit Test ve Integration Test yazımı daha kolay hale geliyor.
4. Eğer bir feature gereğinden fazla büyürse onu iki feature’a kolaylıkla ayırabilirsiniz.
5. Projeye yeni başlayan geliştiricilerin adaptasyon süresini kısaltıyor.
6. Her feature’ın kuralları farklı olabilir. Bu konuda tamamen özgürsünüz!
7. Okunabilirliği arttırıyor.

Tabi bütün bu avantajlarına rağmen dezavantajlarından da söz etmek gerekiyor. Her feature (ya da her blok) kendi içinde diğerinden bağımsız şekilde ilerlediği için, ortak kullandığınız domainleri burada her feature için yazmanız gerekebilir. Bu da kod tekrarına neden olabiliyor ve geliştirme süresini uzatıyor.

Yine aynı şekilde refactoring kavramı da Vertical Slice Architecture’ın vazgeçilmezleri arasında. Bu süreçleri daha iyi anlayabilmek için Kerievsky’in Refactoring to Patterns kitabını okunmanızı öneririm.

Bu mimariyi kurgulamak istiyorsanız takımınızın; refactoring, DDD, Rich Domain Model tekniklerini iyi anlaması gerekiyor.

Mimarinin nasıl oluşturulacağını detaylı bir şekilde anlatan, benim de okumaktan keyif aldığım değerli dostum Samet Çınar’ın ‘Vertical Slice Architecture Example’ makalesini buraya bırakıyorum.

Kaynaklar:
1. https://jimmybogard.com/vertical-slice-architecture/
2. https://medium.com/@Headspring/why-vertical-slice-architecture-is-better-if-you-know-these-few-things-63251cbe80c6
3. https://www.industriallogic.com/xp/refactoring/
4.https://medium.com/sabancidx/vertical-slice-architecture-sample-d61a3a75604b