Screaming Architecture

SCREAMING ARCHITECTURE

Bir binanın mimari planlarına baktığınızı hayal edin. Bu planlar, bir mimar tarafından hazırlanmış ve binanın planlarını sunuyor olsun. Bu planlar size ne anlatır? Eğer incelediğiniz planlar bir aile konutu içinse, muhtemelen bir ön giriş, bir oturma odasına yönlendiren bir hol ve belki de bir yemek odası göreceksiniz. Yemek odasına yakın bir mesafede muhtemelen bir mutfak bulunacaktır. Belki de mutfak yanında bir yemek alanı ve muhtemelen de ona yakın bir aile odası olacak. Bu planlara baktığınızda, kesinlikle bir aile evine baktığınızdan şüphe duymayacaksınız. Mimari plan “EV” diye bağıracaktır.

Şimdi bir kütüphanenin mimarisine baktığınızı düşünün. Büyük bir giriş, giriş/çıkış görevlileri için bir alan, okuma alanları, küçük konferans odaları ve kütüphanedeki tüm kitapları tutabilecek galeri galeri göreceksiniz. Bu mimari plan, “KÜTÜPHANE” diye bağıracaktır.

Bu planları yazılım mimarinizin fonksiyonlarından classlarına, classlarından klasörlerine kadar her noktada görebiliyor olmamız gerekli. Yazılımın folder structure’ını incelerken dahi frameworke değil yazılımın amacına dair bilgi edinebilmeliyiz.

 Peki, uygulamanızın mimarisi ne diye bağırıyor? En üst düzeydeki dosya yapısına ve en üst düzey paketteki kaynak dosyalarına baktığınızda, size “Sağlık Sistemi,” “Muhasebe Sistemi,” veya “Envanter Yönetim Sistemi” diye mi bağırıyor? Yoksa “Rails,” “Spring/Hibernate,” veya “ASP” diye mi bağırıyor?

Mimariler frameworkler hakkında olmamalıdır. Mimariler frameworkler tarafından sağlanmamalıdır. Frameworkler, kullanılacak toollardır, uyum sağlanacak mimariler değildir. 

BİR MİMARİNİN AMACI NEDİR?

İyi mimariler, mimarların framework, tool ve environment’lara bağlanmadan, use caselere odaklanarak bu use caselarını destekleyen yapıları güvenle tanımlayabilmelerini sağlar. Bir evin planlarını tekrar düşünün. Mimarın ilk endişesi, evin kullanılabilir olmasını sağlamaktır – tuğlalardan yapıldığından emin olmak değil. Gerçekten de mimar, planların kullanım amacını karşıladığından emin olduktan sonra, ev sahibinin dış malzeme konusunda (tuğla, taş veya sedir) daha sonra karar verebilmesini sağlamak için çaba gösterir. Yani bu konuları öteleyebilir açık kapı olarak bırakabilir. İyi bir yazılım mimarisi; frameworkler, veritabanları, web sunucuları ve araçlar hakkındaki kararların ertelenmesine ve geciktirilmesine olanak sağlamalıdır. Frameworkler, açık bırakılacak seçeneklerdir. İyi bir mimari, Rails, Spring, Hibernate, Tomcat veya MySQL gibi kararları projenin daha ilerleyen aşamalarına kadar ertelemeyi mümkün kılar. İyi bir mimari, bu kararları değiştirmeyi de kolay hale getirir ve use caselere odaklanır ve bunları diğer konulardan ayırır.

MİMARİ İÇİN DETAY KONULAR

Database Bir Detaydır

Mimari bir bakış açısından, veritabanı bir entity değildir. Veritabanının bir yazılım sisteminin mimarisiyle olan ilişkisi, evinizin mimarisine olan bir kapı tokmağı ilişkisi gibidir. Bu ifadelerin tartışmaya açık ve tepki çekme potansiyeli olduğunun farkındayım. İnanın bana, bu konuda çok tartışma yaşadım. Bu yüzden açık olayım: Burada bahsedilen veri modeli değil. Uygulamanızdaki veriye verdiğiniz yapı, sistem mimarisi açısından son derece önemlidir. Ancak veritabanı, veri modeli değildir. Veritabanı bir yazılım parçasıdır. Veritabanı, veriye erişim sağlayan bir yardımcı programdır. Mimarinin bakış açısından, bu yardımcı program düşük düzeyli bir detaydır – bir mekanizmadır. Ve iyi bir mimar, düşük düzeyli detayları mimarisine izin vermez.

Bu gerçeklik, veritabanının bir detay olduğunu söylememin nedenidir. Veritabanı, veriyi disk yüzeyi ile RAM arasında ileri geri taşımak için kullandığımız bir mekanizmadan ibarettir. Veritabanı, gerçekte, verilerimizi uzun vadeli olarak sakladığımız büyük bir bit kovasından başka bir şey değildir. Ancak, veriyi nadiren bu formda kullanırız.

GUI&Web Bir Detaydır

Web bir mimari midir? Sisteminiz web üzerinden mi dışa açılıyor, bu durum sistem mimarisini belirler mi? Tabii ki hayır!  Web, bir teslim mekanizmasıdır – bir I/O cihazıdır – ve uygulama mimariniz buna uygun olmalıdır. Uygulamanızın web üzerinden teslim edilmesi, bir ayrıntıdır ve sistem yapınızı domine etmemelidir. Aslında, uygulamanızın web üzerinden teslim edileceği kararı ertelenmesi gereken bir karardır. Sistem mimariniz, dışa nasıl açılacağı konusunda mümkün olduğunca bilgisiz olmalıdır. Mimariyi temel mimariye gereksiz karmaşıklık veya değişiklik getirmeden bir konsol uygulaması olarak, bir web uygulaması olarak hatta bir web service uygulaması olarak teslim edebilmelisiniz. Business rulelarınızı UI’ınızdan ayrıştırmalısınız. GUI bir detaydır WEB de bir GUI’dir.  Ve bir yazılım mimari olarak, bu gibi ayrıntıları, temel iş mantığınızdan ayrı tutan sınırların arkasına koymak istersiniz.

Frameworkleri Birer Detaydır

Yazılımcılar ile kullandıkları frameworkler arasında oldukça asimetrik ve sıkı sıkıya bir ilişki vardır. Bir framework kullanırken, frameworkün sağladığı dökümanları okuruz. Bu dökümanlarda yazılımınızı framework ile nasıl entegre edeceğiniz konusunda bilgiler vardır. Genellikle bu, mimarinizi framework etrafına sarmayı gerektirir ve yazılımınızı framework’ün temel sınıflarından türetmenizi ve framework’ün olanaklarını iş nesnelerinize dahil etmenizi önerir. Framework geliştiricileri, uygulamanızı mümkün olduğunca sıkı bir şekilde framework ile bağlamanızı önerir.

Framework geliştiricisi için, kendi frameworküne bağlanmak bir risk değildir. Aslında framework geliştiricisi, framework ile evlenmenizi istiyor – o framework büyük, uzun vadeli bir taahhütte bulunmanızı istiyor. Ve yine de, hiçbir durumda framework size karşılık gelen bir taahhütte bulunmayacak. Bu tek yönlü bir evliliktir. Sen tüm riski ve yükü alırsın; framework hiçbir şey almaz.

Riskler nelerdir? İşte düşünmeniz için sadece birkaç tanesi.

• Framework mimarileri genellikle çok temiz değildir. Fameworkler, dependency rule’ı ihlal etme eğilimindedir. Sizi kodlarını kendi iş nesnelerinize -entitiylerinize!- miras almaya davet ederler! Frameworkler, kendini mimarinin en içteki çemberinize sıkıca bağlamak istiyor bir kere içeri girdi mi de o framework geri çıkmıyor. Nişan yüzüğü parmağınızda ve orada kalacak.

• Framework, uygulamanızın bazı erken özelliklerine yardımcı olabilir. Ancak ürününüz olgunlaştıkça, framework olanaklarını aşabilir. Eğer o nişan yüzüğünü taktıysanız, zaman geçtikçe framework’ün size karşı mücadele ettiğini göreceksiniz.

• Framework, size yardımcı olmayan bir yönde evrilebilir. Yeni sürümlere yükselmek zorunda kalabilirsiniz, size yardımcı olmayan yeni sürümlere geçmek zorunda kalabilirsiniz. Hatta kullandığınız eski özelliklerin kaybolduğunu veya sizinle başa çıkmanız zor değişikliklere uğradığını görebilirsiniz.

• Daha iyi bir framework çıkabilir ve bu geçmek istediğiniz bir framework olabilir.

Çözüm nedir? Framework ile evlenmemek! Tabiki çeşitli frameworkler kullanabilirsiniz; sadece mimarinizi frameworklere sıkı sıkıya bağlamamalısınız.

Framework business entitylerinizi kendi temel sınıflarından türetmenizi istiyorsa hayır deyin! Bunun yerine proxy’ler türetin ve bu proxy’leri business rulelarınıza eklenti olan bileşenlerde tutun. Frameworklerin core kodunuza girmesine izin vermeyin. Bunun yerine, dependency rule’u izleyerek bunları core kodunuza bağlanan bileşenlere entegre edin.

Her frameworke kuşkuyla bakın. Şüpheci bir gözle inceleyin. Evet, yardımcı olabilir, ama hangi maliyetle? Kendinize şunu sorun İ Onu nasıl kullanmalısınız ve ondan nasıl korunmalısınız?  Frameworkün mimarinizi ele geçirmesini engelleyen bir strateji geliştirin

TEST EDİLEBİLİR MİMARİLER

Eğer sistem mimariniz tamamen “use case”lerle ilgiliyse ve “framework”leri uzakta tuttuysanız, o zaman tüm bu use caselere frameworkler olmadan unit test yazabilmelisiniz. Unit testlerinizi çalıştırmak için web sunucunuzun çalışması gerekmemeli. Unit testlerinizi çalıştırmak için bağlı bir veritabanına ihtiyacınız olmamalı. Entity nesneleriniz, frameworklere, veritabanlarına veya diğer karmaşıklıklara bağımlılığı olmayan sıradan nesneler olmalıdır. Use case nesneleriniz, Entity nesnelerinizi koordine etmelidir. Sonuçta, hepsi bir arada, frameworklerin karmaşıklıkları olmadan yerinde unit test edilebilmelidir.

SON OLARAK

Mimarınız, okuyuculara sistem hakkında bilgi vermelidir, sistemde kullandığınız framework hakkında değil. Eğer bir sağlık sistemini inşa ediyorsanız, yeni programcılar kaynak reposuna baktıklarında ilk izlenimlerinin, “bu bir sağlık sistemidir.” olması gerekir. Bu yeni programcılar, sistemimizin tüm use caselerini öğrenebilmeliler, ancak sistemimizin nasıl dışa açıldığını hala bilmemeliler. Size gelebilirler ve şunları söyleyebilirler: “Modellere benzeyen bazı şeyler görüyoruz – ama view ve controllerlar nerede?” Ve siz şöyle cevaplamalısınız: “bunlar şu anda bizi ilgilendirmeyen detaylar. Onlar hakkında daha sonra karar vereceğiz.”