Yazılım Mimarileri

Merhabalar, bu yazımda yazılım mimarilerinden ve proje geliştirme sürecinde neden bu kadar önemli olduklarından bahsedeceğim. Hepimiz yazılım geliştirirken sadece kod yazmanın yeterli olmadığını biliriz; iyi bir mimari, projenin gelecekte nasıl büyüyeceğini, ne kadar kolay bakım yapılabileceğini ve yeni özelliklerin ne kadar hızlı eklenebileceğini doğrudan etkiler. Bu yazıda, en çok kullanılan yazılım mimarilerini, avantajlarını ve hangi durumlarda tercih edilebileceklerini sade bir dille anlatmaya çalışacağım.

Yazılım mimarileri , oluşturduğum veya bulunduğumuz bir projenin nasıl parçalara bölüneceğini hangi işlemlerin ne tarafta kullanıcağını oluşturan bir mimaridir. Yani kısaca yazılım mimarisi bir yazılım uygulamasının temel yapısını ve bileşenlerini düzenleyen , belirleyen ve tasarlayan disiplindir.

YAZILIM MİMARİLERİN TEMEL KULLANIM AMAÇLARI

• Tekrar Kullanılabilirlik ; projede oluşturduğumuz bir UI buttonunu istediğimiz yerde tekrardan çağırarak kullanabiliriz.
• Karmaşıklığı Yönetmek ; büyük projeler de tek bir dosyada bulunması yerine her bölümün kendine ait bir yerde olması hem takım içi karmaşıklığı giderir hem de bir değişiklik yapılırken veya geliştirme yapılırken zaman kaybı olmaz.
• Ekip Çalışmasının Kolaylaştırılması
• Modülerlik Ve Kolay Bakım ; kullanım avantajı istediğin kısmı ayrı ayrı test edebilirsin tek bir kod sayfasında olsa hepsini test edersin ama farklı modüler sayfalarında olduğu için isteğe bağlı şekilde ayrı şekilde test yapılabilir .
• Risk Yönetimi ; yazılım mimarileri proje de risk oluşmasını minimalize eder ve bu alanların yani sorunların ve risklerin belirlenmesinde hızlı bir şekilde tespit edilmesini sağlar.

!!! İsteklere cevap verebilen değişimi daha az efor isteyen bir uygulamamız var ise bir sorun çıktığında bunu düzeltmemiz daha rahat olacaktır.

!!! Mimarinin temel amacı minimum efor maksimum performanstır.

SOLID Prensibi Nedir?

Geliştirilen yazılımın esnek , yeniden kullanılabilir , sürdürülebilir ve anlaşılmasını sağlayan bir prensibtir. 5 temel OOP ilkesidir. Proje’nin büyüklüğü artarken karmaşıklığın önüne geçmiş olursunuz SOLID prensibi ile .

Single Responsibility Principle(Tek Sorumluluk Prensibi)

Oluşturulan sınıfın bir sorumluluğu olmalıdır.Bu prensip sınıfların daha anlaşılır , okunaklı ve daha sürdürülebilir hale getirir.

Open-Closed Principle(Açık-Kapalı Prensibi)

Bir sınıf veya fonkisyon hali hazırda var olan özelliklerini korumalı bu özellikler değişmiyor olmalı . yani özellikler değişmeyecek ama yeni özellik eklenebilecek bir yapıya sahip olmalı.

Liskov Substiution Principle(Liskov yerine geçme prensibi)

Bir alt sınıf, üst sınıfın yerine geçtiğinde hiçbir sorun çıkarmamalı.

Interface Segregation Principle(Arayüz Ayrımı Prensibi)

Kullanmayacığımız methodlar içeren büyük arayüzler oluşturmamalıyız. projenin karmaşıklığını önlemek için gerekli ve sadece kullandığımız arayüz bileşenlerini oluşturmalıyız.

Arayüzümüzü tek bir sorumlulukta değil de ayrı ayrı parçalar halinde oluşturmalıyız yani özelleştirilmiş arayüzler olmalıdır.

• gereksiz bağımlılıklardan kaçınılır.
• kod karmaşıklığı önlenir .

Dependency Inversion Principle(Bağımlılıkları Tersine Çevirme Prensibi)

Sınıflar somut sınıflara değil Interface/Protocollere bağlı olmalıdır.

• Test edilebilirliği kolaylaşır.
• kodun parçaları birbirine sıkı sıkıya bağlı olmaz

SIK KULLANILAN YAZILIM MİMARİLERİ

MVC(Model-View-Controller)

Model: iş mantığını ve veriyi tutar.

View: Interface kısmını oluşturur.

Controller: kullanıcıdan gelen istekleri alır modeli kullanarak UI’ı günceller.

!!!! Basit anlaşılır bir yapıya sahiptir , katmanlar ayrı olduğu için kod bakımı kolaydır.

MVVM(Model-View-ViewModel)

Model: sadece iş mantığımın oluşturulduğu yer.

View: Interface ‘in oluşturulduğu kısım.

ViewModel: model ve view arasında iletişimin sağlanmasını oluşturan kısımdır.

!!!! Test yazması kolaydır , kod bakımı kolaydır , UI ve iş mantığı tamamen birbirinden ayrıdır.

Clean Architecture

Katmanlar arası bağımlılığı ters çevirerek uzun ömürlü , modüler bir sistem kurar .

• merkezde iş kuralları → entities
• onun etrafında → use cased
• daha dışta → UI , veritabanı , Apı vb.

!!!! Platform bağımsız çekirdek değişse bile UI aynı kalır. Test yazması kolaydır . Kod uzun yıllar sorunsuz çalışır.

Microservices Architecture(Mikroservis Mimarisi)

• Uygulamayı küçük bağımsız servisler olarak geliştirme mimarisidir.
• Her servis kendi veritabanına ve iş mantığına sahiptir.
• Servisler Apı üzerinden haberleşir

!!! Takımlar bağımsız çalışabilir , bir hata olduğunda tüm servis çökertilmez aytı olarak o kısıma bakılır , sadece ihtiyaç duyulan servis büyütülüp geliştirilebilir.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Bu yazımda, yazılım mimarilerinin ne olduğunu, en sık kullanılan türlerini ve hangi senaryolarda tercih edilebileceklerini paylaştım. Doğru mimari seçimi, yalnızca bugünkü ihtiyaçlarınızı değil, projenizin gelecekteki sürdürülebilirliğini de garanti altına alır. Umarım bu yazı, mimari seçimlerinizde size fikir verir ve projelerinizi daha sağlam temeller üzerinde inşa etmenize yardımcı olur. Bir sonraki yazıda görüşmek üzere, iyi kodlamalar! 👋