Yazılım

Onion Architecture / Soğan Mimarisi

KASIM 6, 2016

Soğan mimarisini araştırdığımda Türkçe’yle yazılmış çok bir kaynak göremedim ben de buraları yeşillendireyim dedim. Peki nedir bu soğan mimarisi neden kullanılmalıdır?

Soğan mimarisi/ Onion Architectiure 2008 yılında Jeffrey Palermo tarafından önerilmiştir. Soğan mimarisini incelediğimizde çok katmanlı mimarinin problemlerine çözüm getirdiği görülmektedir. Çok katmanlı mimari de şekilde olduğu gibi UI katmanı önce Business Logic / iş mantığı katmanıyla iletişime geçmekte ve sonrasında Business Logic / iş mantığı katmanı data/veri katmanıyla haberleşmektedir. Bu katmanlar birbirlerine bağlı ve karışıktır ve bu yüzden katmanlar bağımsız kalamazlar.

Örnek olarak açıklamak gerekirse uygulamanızda button_submit veya page_load eventleri içinde benzer kodlara sahipsiniz ve bu benzer kodları tek bir metod içinde yazıyorsunuz sonrasında yeni gelen geliştiriciler sistemde değişiklik yapmak isteyecekler ve yeni iş mantığı eklemeye devam edecekler bu durum karışıklığa neden olacak ve sistemi anlamasını ve bakımını zorlaştıracaktır.

Dataya erişim tekniklerinin sıklıkla değişmesi Çok katmanlı mimaride bir başka problem olarak yorumlanabilir. Uygulamanızın erişim tekniklerindeki değişikliğe esnek olması beklenirken birbirine bağlı olan katmanlar işi zorlaştırır.

Peeki soğan mimarisi bu tarz sorunlar için ne gibi çözümler getirmiştir?

Öncelikle soğan mimarisi adından da anlaşıldığı gibi soğan halkalarına benzemektedir. Buradaki her halka/katman içindeki katmanlara bağlıdır fakat dışındaki halkalara bağlı olmak zorunda değildir. Yani tüm bağlantılar merkeze doğrudur. En içteki domain model, iş ve davranış nesnelerini sunar. Uygulamalarda katman sayısı değişkenlik gösterebilir fakat her zaman en içteki katman domaindir. İlk katmandan sonraki katmana genellille repository interface denilen davranışları kaydetmeyi ve almayı sağlayan interface’ler yerleştirilir. İnterface uygulamanın merkezinde kalmaktadır. En dış katman sıklıkla değişen UI,Infrastructure ve Testler gibi şeylere ayrılmıştır. Bunlar uygulamanın merkezinden özellikle izole edilir. Grafikte dikkat ederseniz datanın saklandığı DB, file görünmemektedir. DB yapının dışında kalmaktadır ve Infrastructure’da repository interface’e implement edilen classlar bulunmaktadır ve bu classlar dataya erişim yöntemini içerir.

Genel kültür tadında yukarıda açıkladım şimdi konuyu merak edip projede bu mimariyi kullanayım diyenelr için her bi katmanı daha detaylı inceleyelim.

Domain /Core Layer: En içteki domain katmanı tüm domain nesnelerini(object’lerini) ve interface’leri tutar. Burada dikkat edilecek nokta referans olarak diğer katmanlardan hiçbirini bu projeye dahil etmiyor oluşumuz.

Domain klasörünün altında ekran görüntüsündeki gibi 2 proje oluşturulabilir. Bir tanesi Domain.Entities burada object’leri tutarız, diğer projede ise Domain.Interfaces bu objelerin interfacelerini tutarız.

Service Interface Layer: Bu katmandaki interfacelerde sıklıkla kullanılan Ekleme/Silme/Kaydetme işlemleri bulunur. Bu katmanda dikkat edilmesi gereken servis interfaceleri implementationları tuttu bu da bağlantıları ve Seperation of Concerns(SoC)’ u bağlanmamış gösterir.

Application Services Layer: Servis implementation’ları datayı repository’lerden getirir ve UI/kullanıcı arayüzü tarafından gelen requestleri/istekleri işler. Bu halka Infrastructure’dan UI’ tarafına datanın iletilmesini sağlayan ara katman rolündedir.

Referanslara bakıldığında domain entities ve omain interface’in referans edildiği görülür.

Infrastructure Layer:


Kaynak: understanding onion architecture

Yusuf SEZER 2.4.2019
Yazı için teşekkürler.

POPÜLER İÇERİK

C/C++ da oyun yazmak ya da grafik kütüphanesiyle ilgili birşeyler yapmak istiyorsanız: Öncelikle iki dosyaya ihtiyacınız var bunlardan biri libbgi.a dosyası buradan indiriniz. Diğer graphics.h dosyasını ise buradan indiriniz.

OCAK 24, 2011 - 78 YORUM

Dev-C++ Derleyicisine graphics.h Kütüphanesini Ekleme