Yazılım Mimarisi Nedir?

Bir bina yapılmaya başlamadan önce mimarlar tarafından projenin ön çizimi, tasarımı çizilir. Tıpkı bunun gibi bir yazılım projesinin de yapılmaya başlamadan önce planlanması gerekir. Bu planlamaya “Yazılım Mimarisi” bu planı tasarlayan kişilere de “Yazılım Mimarı” denir. Mimari, yazılım uygulamasının bir donanımın, ağların ve bir işletmenin diğer bileşenleriyle nasıl etkileşime gireceğini ana hatlarıyla anlatan eksiksiz bir tasarım belgeleri seti içerir. Böylelikle yazılım geliştiricilerin izleyeceği yol genel hatları ile belirlenmiş olur.

Yazılım Mimarisinde Olması Gereken Özellikler Nelerdir?

İşlevsellik: Yazılımın kullanım amacına göre performans düzeyini ifade eder.

Güvenilirlik: Ürünün verilen koşullar altında istenilen işlevselliği sunabilme kabiliyetini ifade eder.

Kullanılabilirlik: Yazılım ürününün ne ölçüde kolaylıkla kullanılabileceğini ifade eder.

Performans: İşlem hızı, yanıt süresi, kaynak kullanımı, çıktı ve üretkenlik dikkate alınarak yapılan tahmini ifade eder.

Desteklenebilirlik: Programlama geliştiricilerinin yazılımı bir platformdan diğerine herhangi bir değişiklik yapmadan veya minimum değişiklikle aktarabilme kolaylığı anlamına gelir.

Kendine Güven: Bağımsız servislerden birinin kesintiye uğramasına rağmen optimum performans gösterme yeteneğini ifade eder.

Yazılım mimarisini yukarıda bahsedilen özelliklere sahip olması ve başarılı bir mimari tasarım olması için Yazılım Mimarisi İlkeleri ‘ne (S.O.L.I.D Principles) bağlı kalmalıdır.


Tek Sorumluluk İlkesi (Single Responsibility Principle)

Her sistem yeteneğinin (örneğin hizmet/modül/api) yalnızca bir sorumluluğu ve dolayısıyla bir değişiklik nedeni olmalıdır. Sorumlulukları mümkün olduğunca dar tutmak, kullanıcıların amaçlanan amacı bilmesi anlamına gelir ve bu da daha az hataya yol açar.

Açık-Kapalı İlkesi (Open-Closed Principle)

Bu ilke, bir sistem davranışını değiştirmeden genişletmenin tercih edilebileceğini varsayar. Gereksinimlerdeki değişiklikleri önceden tahmin etmeye çalışmak çoğu zaman iyi bir fikir olmasa da (aşırı karmaşık tasarımlara yol açabileceğinden), yeni işlevleri mevcut bileşenlerde minimum değişiklikle uyarlayabilmek, uygulamanın uzun ömürlü olmasının anahtarıdır.

Liskov İkame İlkesi (Liskov Substitution Principle)

Herhangi iki bağımsız hizmet, gerektiğinde bir API çağrısı aracılığıyla birbirleriyle iletişim kurabilmelidir. Ayrıca, aynı sözleşmeye sahip iki hizmet, genel sistemi değiştirmeden birbirleri arasında ikame olarak hareket edebilmelidir.

Arayüz Ayrıştırma İlkesi (Interface Segregation Principle)

Arayüzler/sözleşmeler mümkün olduğunca ayrıntılı ve müşteriye özel olmalıdır, bu nedenle çağrı yapan istemciler, kullanmadıkları işlevselliğe bağlı değildir. Bu, Tek Sorumluluk ilkesiyle el ele gider: arayüzleri parçalayarak, rollere/sorumluluklara göre ayırarak Kompozisyon'u ve türev modülleri gereksiz sorumluluklarla birleştirmeyerek Dekuplaj'ı tercih ederiz

Bağımlılık Tersine Çevirme İlkesi (Dependency Inversion Principle)

Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır; her ikisi de soyutlamalara dayanmalıdır. Aynı şekilde, soyutlamalar ayrıntılara bağlı olmamalıdır, ancak ayrıntılar soyutlamalara bağlı olmalıdır. Bu ilke, aralarındaki bağımlılıkları ortadan kaldırmak için üst düzey ve alt düzey yazılım bileşenleri veya katmanları arasında bir arabirim soyutlaması sunar.