ASP.NET Monolithic Clean Architecture

14 Mart 2020 Ayaz ASP.NET

Neden Temiz Mimariye ihtiyacımız var?

Çünkü iyi bir yazılım mimarisi, anlaşılabilir, geliştirmesi basit, bakımı ve dağıtımı kolaydır. Aslında kolaydan kasıt, sistemin maliyetini olabildiğince indirmek ve geliştiricilerin verimliliğini olabildiğince artırmaktır.

Örnek projeyi github üzerinden indirmek veya görüntülemek için https://github.com/ayzdru/MonolithicCleanArchitecture adresine gidebilirsiniz.

 

Principles (İlkeler)

  • Separation of Concerns (SoC)

Programlama kodlarını (method | class | project) özellik ve işlevine göre birbirinden soyutlama ve ayırmadır.

Yüzlerce satırlık god class'lardan kaçınmalıyız.

Spaggetti kod, kod takibinin zor olduğu, okunabilirliği düşük kodlardır.

Benim tabirimle yaz-geç ile yazılmış kodlar, yapmayın, yazıktır, günahtır. ༼ つ ◕_◕ ༽つ

Projeyi katmanlara ayırırsak üç büyük şunlardır;

  1. Data Access (Veri erişimi)
  2. Business Rules and Domain Model (İş Kuralları ve Domain Model)
  3. User Interface (Kullanıcı arayüzü)

  • Single Responsibility

Separation of Concerns ile birlikte çalışır. Yazılım projesi geliştirirken, her metodun, sınıfın hatta projenin kendi işi dışındaki başka işlerden sorumlu olmamasıdır. Yani yukarıdaki resimde isviçre çakısı gibi bir metot size her şeyi yaptığında daha kullanışlı gelebilir. Ama yazılımda böyle bir şey söz konusu değildir. Daha anlaşılabilir olması gerekmektedir. Bu yüzden bütün kodlar kendi işini yapmak zorundadır.

  •  Don't Repeat Yourself (Kendinizi tekrar etmeyin)

Şöyle söyleyeyim aynı işi yapan kodları bir sürü yere kopyaladınız ve kopyaladığınız kodlar sıkıntılı ve her yere dağılmış. Tek tek bulup, hepsini düzeltmeniz gerekecek. Zaman ve emek kaybından başka bir şey olmayacak.

  •  Dependency Inversion (Bağlılığı Tersine Çevirme)

Örnek olarak Email göndermeye yarayan bir servisimiz var ve bir gün kullanıcılara SMS'de göndermek istiyoruz. Projeye yeni bir özellik eklersek diğer kodları etkilememelidir. Bir interface oluşturup,  her iki servisimizde bu interface'i kullanarak, nesnelerin birbirine bağımlılığını ortadan kaldırabiliriz.

public interface IMessage  
{
    void Send();
}
 
public class EmailService : IMessage
{
    public void Send()
    {
    }
}
 
public class SmsService : IMessage
{
    public void Send()
    {
    }
}

Onion Architecture (Soğan Mimarisi)

Domain-Centric (Domain merkezli) bir tasarım olan Onion mimarisinin her katmanı soğan halkası gibi düşünülmüştür. Burada her üst düzey katman, merkezi katmanlara bağlıdır. Herhangi bir üst düzey katmanda yapılan değişiklik merkezi katmanları etkilemez. Gördüğünüz gibi en üst katmanlardan biri Test katmanıdır.

Temiz Mimaride Olması Gereken Özellikler

  • Readability (Okunabilirlik)

Ekibe yeni bir programcı katıldığında kolay anlayabilmesi ve projeye hızlı bir şekilde adapte olabilmesi gerekmektedir.

  • Testability (Testedilebilirlik)

Projeyi test etmek sizi ileride olabilecek zarardan ve zaman kaybından kurtarır.

Eğer projenin testinin yapmazsanız, müşteri de sizin testinizi yapmaz.
  •  Reusability (Tekrar Kullanılabilirlik)

Yazdığımız kodları tekrar kullanabiliyor olmamız gerekiyor.

  • Maintainability (Sürdürülebilirlik)

Projenin bakımının ve onarımının kolaylıkla yapılabilmesi gerekiyor.

  • Extendability (Genişletilebilirlik)

Mevcut modülleri silmeden kolaylıkla genişletebilmemiz gerekiyor.

 Onion Architecture Test Yapısı

 

Daha teknik detay için;

https://github.com/ayzdru/MonolithicCleanArchitecture üzerinden yazdığım örnek kaynak kodu inceleyebilirsiniz.

Sağlıcakla kalın...

Yorumlar kapalı