Clean Architecture Kitabından Notlar – Yazılım Mimarisi Sınırları

YAZILIM MİMARİSİ 

Yazılım mimarisi büyük oranla sınırları doğru çizebilmek ile ilgilidir.  Bu sınırlar yazılım componentlerini birbirinden ayıran, componentlerin birbirleri hakkında bilgileri direkt olarak bilmesini kısıtlayan sınırlardır.

Yazılım mimarisinin bir diğer amacı ise bir projeyi build ve maintain edecek insan sayısını minimize ederek, belli kararları sonraya bırakmaktır. Peki bu kararlar hangi kararlardır? Business requirement ile gerçek anlamda ilişkisi olmayan kararlardır. Örneğin, framework seçimi, database seçimi, utility libraryleri, ve benzeri. Aksi halde başlangıçta elimizde core bir domain problemi ve işletilmesi gereken bir business çözümlenmesi gereken bir ihtiyaç varken bu ihtiyaç bir anda teknolojik bir probleme dönüşebilir. Asıl ihtiyaç unutulup günlerce mongo mu, sql mi vs gibi tartışmalarla vakit harcanabilir. iyi bir yazılım mimarisi bu kararları sonraya bırakabilir ve bu kararların zamanı geldiğinde bu kararların alınıp, uygulanma aşamasında sisteme olan entegrasyon etkisini minimum düzeyde tutabilir.

SINIRLAR

Yukarıda da bahsettiğimiz gibi, sınırları seperation of concern prensibi çerçevesinde, birbirleriyle ilgisi olmayan componentleri ayırmak için çizeriz. Örneğin, GUI bileşenleri, business rule ile ilgilenmez arada bunları ayıran bir sınır olmalıdır yahut database ile GUI componentleri birbirinden ayrı componentlerdir ve arada sınır olmalıdır.

Bu bazılarımız için alışılmışın dışında olabilir çünkü çoğu old-fashion projede business rule’ları database operasyonları ile direkt olarak ilişkilidir. Hatta bazı mimarilerde database direkt olarak business rulelarını tutar. Ancak, bu yapı ideal yapıdan uzaktır. Database, business rule’larının dolaylı olarak kullanabileceği bir tooldur. Tüm business fonksiyonlarının bilmesi gereken tek şey bir yerlerde kullanabilecekleri data operasyon fonksiyonları olduğudur ki bu da bizim database operasyonlarını bir interface’in arkasına koymamızı sağlar. Bu da bizi direkt olarak Dependency inversion, open closed gibi prensipleri uygulayabilir hale getirir. Database scheması, query language ya da database detaylarıyla ilgilenmez.

Aşağıdaki örnekte de görebileceğiniz gibi business rulelar database interfacesini data get ya da save etmek için kullanır. DatabaseAccess ise interfacesi implemente eder ve database operasyonlarını implemente eder.

Peki burada boundary line tam olarak nerde? boundary line tam da inheritance ilişkisinin bulunduğu yerden çizilir. Çünkü business rule sadece interface’i bilir ve interface’ten sonrası dependency inversion noktasıdır. Sınır çizmeyi sadece katman bazında düşünmek yanlış olur.

Burada bir diğer önemli nokta ise tüm okların database access classtan çıkıyor oluşudur. Yani diğer hiç bir class database access classın varlığını bilmez. Bu, DatabaseInterfacein BusinessRules bileşeninde, DatabaseAccess sınıflarının ise Database bileşeninde durduğu anlamına gelir. Line yönü önemlidir. Veritabanının İş Kuralları için önemli olmadığını, ancak Veritabanının İş Kuralları olmadan var olamayacağını gösterir.

Bu noktada, business rulelarının herhangi bir database çeşidini kullanabileceğini görebiliriz.  Database componenti Oracle, mySql, couch, ms sql istenilen tool ile implemente edilebilir. Business rule bunu umursamaz. Bunun anlamı hangi databasein kullanılacağı ve implementasyonu gibi database kararları business kararlarından arındırılmış durumda, sonraya ertelenebilir durumdadır.

Benzer mantık GUI componenti için de geçerlidir. Bazen yazılım geliştiriciler ve müşteriler sistem hakkında kafa karışıklığına düşerler. GUI’i görürler ve GUI’ın sistem olduğunu düşünürler ve bir sistemi GUI üzerinden tasarlarlar. Onlar için elle tutulur ekranlar olmalı ve hızlı bir şekilde çalışır hale gelmelidir ancak bir şeyi atlarlar. GUI bir detaydır. Burada, arkada çalıştıran bir sistem vardır ki aslında hiç bir şekilde GUI’a dahi ihtiyaç duymaz. Bu da bizi kez daha GUI ve Business Rule’ların ayrıştırılmasının önemi noktasına götürür. Yukarıdaki gibi bir bağımlılık şemasına sahip isek elimizdeki GUI kolay bir şekilde başka bir GUI ile replace edilebilir durumda olur.

Aslında yazılım geliştirme hikayesi scalable ve maintainable ve bunlar için pluginler yaratmaktır. Core business rule opsiyonel ya da farklı şekilde implemente edilecek diğer tüm komponentlerden bağımsız ve ayrı geliştirilmeli. Yukarıdaki mimariye baktıgımızda user interface bir plugindir. Aynı şey bir database için de geçerlidir.

SONUÇ OLARAK

Yazılım mimarisinde sınırları ayrıştırmak istiyosanız, öncelikle yazılım sistemlerinizi componentlere ayrıştırmalısınız. Bu componentlerin bir kısmı business rulelar, diğerleri ise direkt olarak core business fonksiyonelliğiyle ilgili olmayan kodlar. Amaç scalable ve maintainable bir plugin mimarisi tasarlayabilmektir.