Bana Mimariyi Yeniden Düşündüren Mülakat Sorusu: Alan Odaklı Tasarımı Anlamak

Bana Mimariyi Yeniden Düşündüren Mülakat Sorusu: Alan Odaklı Tasarımı Anlamak

Modern yazılım geliştirme dünyasında, karşılaşılan problemlerin karmaşıklığı her geçen gün artmaktadır. Basit bir “Nasıl bir mimari kurardınız?” sorusu bile, tecrübeli bir geliştiricinin yıllardır edindiği alışkanlıkları sorgulamasına yol açabilir. Bu makale, tam da böyle bir mülakat sorusunun tetiklediği mimari bir uyanışı ve bu uyanışın bizi Alan Odaklı Tasarım (Domain-Driven Design – DDD) felsefesine nasıl yönlendirdiğini anlatmaktadır.

Mülakat Sorusu ve Uyanış Anı

Bir mülakat sırasında, “Çok büyük ve karmaşık bir e-ticaret sisteminin sipariş yönetimi modülünü nasıl tasarlardınız?” sorusuyla karşılaştım. İlk başta aklıma gelenler, veri tabanı şemaları, API katmanları ve mikroservisler gibi teknik detaylardı. Ancak mülakatı yapan kişi, “Peki, işin kendisi ne istiyor? Bu sistemin ‘sipariş’ kavramı sizin için ne anlama geliyor?” diye derinlemesine sorduğunda, alışılagelmiş düşünce yapımın sınırlarına ulaştığımı fark ettim.

Geleneksel Yaklaşımların Sınırları

Geleneksel yazılım geliştirme yaklaşımları genellikle veritabanı merkezli veya teknoloji odaklıdır. Önce veritabanı şeması tasarlanır, ardından bu şema etrafında CRUD (Create, Read, Update, Delete) operasyonları tanımlanır. Bu yaklaşım, basit uygulamalar için yeterli olabilirken, iş süreçlerinin karmaşıklaştığı, farklı paydaşların farklı beklentilere sahip olduğu büyük sistemlerde yetersiz kalır. İş mantığı, farklı katmanlara dağılır, anlaşılması ve bakımı zorlaşır.

Sorunun Tetiklediği Düşünceler

Mülakat sorusu, beni teknik detaylardan ziyade, “işin kendisi”ne odaklanmaya zorladı. Bir siparişin durumu nasıl değişir? İptal edildiğinde veya iade edildiğinde hangi kurallar devreye girer? Bir siparişin “ödendi” durumu, ödeme sistemleri, stok yönetimi ve müşteri hizmetleri için ne anlama gelir? Bu sorular, iş alanının derinlemesine anlaşılmasının, sağlam bir mimarinin temelini oluşturduğunu gösterdi.

Neden Yeniden Düşünmeliyiz?

Yazılım, iş dünyasının bir yansımasıdır. Eğer yazılımımız, temsil ettiği iş alanını doğru bir şekilde modellemiyorsa, kaçınılmaz olarak hatalara, tutarsızlıklara ve sürdürülemez bir yapıya yol açar. Mimariyi yeniden düşünmek, sadece teknik borcu azaltmakla kalmaz, aynı zamanda iş gereksinimlerine daha hızlı ve doğru yanıt verebilen, esnek ve anlaşılır sistemler inşa etmemizi sağlar.

Alan Odaklı Tasarım (DDD) Nedir? Temel Prensipler

Alan Odaklı Tasarım (DDD), karmaşık iş alanlarına sahip yazılım sistemleri geliştirmek için bir yaklaşımdır. Temel amacı, yazılımın, iş alanının modelini yansıtmasını sağlamaktır. Bu, geliştiricilerin ve iş uzmanlarının aynı dili konuşarak, işin temel mantığını yazılıma aktarmasına olanak tanır.

Ortak Dil (Ubiquitous Language)

DDD’nin en temel prensiplerinden biri Ortak Dil’dir. Bu, iş uzmanları ve geliştiriciler arasında, iş alanındaki kavramları tanımlamak için kullanılan ortak bir terimler setidir. Bu dil, kodda, dokümantasyonda ve tüm iletişimde tutarlı bir şekilde kullanılır. Örneğin, bir e-ticaret sisteminde “sepet”, “sipariş”, “ürün” gibi terimlerin herkes için aynı anlama gelmesi sağlanır.

Sınırlı Bağlam (Bounded Context)

Büyük ve karmaşık iş alanları genellikle farklı alt alanlara ayrılabilir. Her bir alt alanın kendi içinde tutarlı bir modeli ve Ortak Dili olabilir. Sınırlı Bağlam, bu alt alanları tanımlar ve her birinin kendi modelini ve dilini izole eder. Örneğin, bir e-ticaret sisteminde “Sipariş Yönetimi”, “Stok Yönetimi” ve “Müşteri İlişkileri” farklı Sınırlı Bağlamlar olabilir. Bu, modellerin birbirine karışmasını önler ve her bir bağlamın kendi içinde tutarlı kalmasını sağlar.

Etki Alanı Modeli (Domain Model)

Etki Alanı Modeli, iş alanının temel kavramlarını, davranışlarını ve ilişkilerini temsil eden bir nesne modelidir. Bu model, iş kurallarını ve mantığını içerir ve genellikle zengin bir nesne yapısına sahiptir. DDD’de, Etki Alanı Modeli, uygulamanın kalbidir ve işin kendisini en doğru şekilde yansıtmaya çalışır.

Katmanlı Mimari (Layered Architecture)

DDD, genellikle Katmanlı Mimari ile birlikte kullanılır. Bu mimari, uygulamanın farklı sorumluluklarını ayrı katmanlara ayırır:

• Kullanıcı Arayüzü/Sunum Katmanı: Kullanıcı ile etkileşimi yönetir.
• Uygulama Katmanı: İş akışlarını koordine eder, Etki Alanı Modeli ile etkileşime girer.
• Etki Alanı Katmanı: İş mantığını, kuralları ve Etki Alanı Modelini içerir. DDD’nin kalbidir.
• Altyapı Katmanı: Veritabanı erişimi, mesajlaşma, dış servis entegrasyonları gibi teknik detayları yönetir.

Bu katmanlama, sorumlulukların ayrılmasını sağlar ve Etki Alanı Katmanı’nın diğer katmanlardan bağımsız kalmasına yardımcı olur.

DDD’nin Yapı Taşları

DDD, Etki Alanı Modelini oluşturmak için çeşitli yapı taşları sunar. Bu yapı taşları, iş mantığını kodda daha net ve ifade edici bir şekilde temsil etmemizi sağlar.

Varlıklar (Entities)

Varlıklar, benzersiz bir kimliğe sahip olan ve yaşam döngüsü boyunca bu kimliği koruyan nesnelerdir. Kimlikleri, niteliklerinden daha önemlidir. Örneğin, bir “Müşteri” veya “Sipariş” bir varlıktır.

public class Siparis
{
    public Guid Id { get; private set; }
    public DateTime SiparisTarihi { get; private set; }
    public SiparisDurumu Durum { get; private set; }
    public List Kalemler { get; private set; }

    public Siparis(Guid id, DateTime siparisTarihi)
    {
        Id = id;
        SiparisTarihi = siparisTarihi;
        Durum = SiparisDurumu.Olusturuldu;
        Kalemler = new List();
    }

    public void SiparisDurumunuGuncelle(SiparisDurumu yeniDurum)
    {
        // İş kuralları burada uygulanır
        if (Durum == SiparisDurumu.IptalEdildi)
        {
            throw new InvalidOperationException("İptal edilmiş siparişin durumu değiştirilemez.");
        }
        Durum = yeniDurum;
    }
}

Değer Nesneleri (Value Objects)

Değer Nesneleri, bir kimliği olmayan, sadece niteliklerinin değeriyle tanımlanan nesnelerdir. Genellikle değişmez (immutable) olurlar. Örneğin, bir "Adres", "Para Birimi" veya "Miktar" bir değer nesnesi olabilir.

public class Adres
{
    public string Sokak { get; private set; }
    public string Sehir { get; private set; }
    public string PostaKodu { get; private set; }

    public Adres(string sokak, string sehir, string postaKodu)
    {
        Sokak = sokak;
        Sehir = sehir;
        PostaKodu = postaKodu;
    }

    // Değer nesneleri için eşitlik karşılaştırması değerlere göre yapılır.
    public override bool Equals(object obj)
    {
        if (obj is Adres other)
        {
            return Sokak == other.Sokak && Sehir == other.Sehir && PostaKodu == other.PostaKodu;
        }
        return false;
    }

    public override int GetHashCode()
    {
        return HashCode.Combine(Sokak, Sehir, PostaKodu);
    }
}

Agregalar (Aggregates)

Agregalar, bir veya daha fazla varlık ve değer nesnesini içeren, tutarlılık sınırlarını tanımlayan bir kümedir. Her agreganın bir kök varlığı (Aggregate Root) bulunur ve dışarıdan yalnızca bu kök varlık aracılığıyla erişilir. Bu, agregate içindeki nesnelerin tutarlılığını korumayı sağlar. Örneğin, bir "Sipariş" ve ona bağlı "Sipariş Kalemleri" bir agreganın parçası olabilir. "Sipariş" burada Aggregate Root'tur.

Etki Alanı Hizmetleri (Domain Services)

Etki Alanı Hizmetleri, belirli bir varlığa veya değer nesnesine doğal olarak uymayan, ancak iş alanının önemli bir parçası olan operasyonları veya iş mantığını barındırır. Örneğin, farklı para birimleri arasında dönüşüm yapan bir hizmet veya bir siparişin birden fazla kurala göre onaylanması gibi.

Depolar (Repositories)

Depolar, agregate köklerinin depolanması, alınması ve yönetilmesi için bir soyutlama sağlar. Etki Alanı Katmanı'nın, veritabanı gibi altyapı detaylarından bağımsız kalmasına yardımcı olur. Bir depo, bir agregate'i bellekten veya kalıcı depolamadan getirip kaydetmekten sorumludur.

Etki Alanı Olayları (Domain Events)

Etki Alanı Olayları, bir agregate içinde veya iş alanında meydana gelen önemli olayları temsil eder. Bu olaylar, sistemin diğer bölümlerinin veya farklı Sınırlı Bağlamların bu değişikliklere tepki vermesini sağlar. Örneğin, "Sipariş Oluşturuldu", "Ödeme Başarılı", "Ürün Stoğu Güncellendi" gibi olaylar.

DDD Uygulama Stratejileri

DDD, sadece taktiksel yapı taşları sunmakla kalmaz, aynı zamanda karmaşık sistemleri yönetmek için stratejik yaklaşımlar da sağlar.

Stratejik Tasarım

Stratejik tasarım, büyük bir iş alanını daha küçük, yönetilebilir Sınırlı Bağlamlara ayırmayı ve bu bağlamlar arasındaki ilişkileri tanımlamayı içerir. Bu, iş alanının genel bir haritasını çıkarmak ve her bir bağlamın kapsamını belirlemek anlamına gelir.

Taktiksel Tasarım

Taktiksel tasarım, belirli bir Sınırlı Bağlam içindeki Etki Alanı Modelini oluşturmak için Varlıklar, Değer Nesneleri, Agregalar, Depolar ve Etki Alanı Hizmetleri gibi yapı taşlarını kullanmayı içerir. Bu, kod seviyesinde iş mantığını ifade etme sürecidir.

Bağlam Haritaları (Context Maps)

Bağlam Haritaları, farklı Sınırlı Bağlamlar arasındaki ilişkileri ve entegrasyon stratejilerini görselleştiren bir araçtır. Bu haritalar, ekiplerin farklı sistemlerin nasıl etkileşim kurduğunu anlamasına yardımcı olur ve entegrasyon sorunlarını önceden tespit etmeyi sağlar.

DDD'nin Avantajları ve Zorlukları

Her mimari yaklaşım gibi, DDD'nin de kendine özgü avantajları ve zorlukları vardır.

Avantajlar: Esneklik, Anlaşılırlık, Bakım Kolaylığı

• Daha İyi İş Anlayışı: İş uzmanları ve geliştiriciler arasında ortak bir dil ve model oluşturarak iş alanının daha derinlemesine anlaşılmasını sağlar.
• Esneklik ve Değişime Direnç: İş kuralları ve mantığı merkezi bir yerde toplandığı için, iş gereksinimlerindeki değişikliklere daha kolay adapte olunabilir.
• Daha Temiz ve Sürdürülebilir Kod: İş mantığının altyapı detaylarından ayrılması, daha okunabilir, test edilebilir ve bakımı kolay kod yazmayı teşvik eder.
• Daha Az Teknik Borç: İş alanını doğru modelleyerek, ileride ortaya çıkabilecek tutarsızlıkları ve yeniden yazma ihtiyaçlarını azaltır.

Zorluklar: Öğrenme Eğrisi, Başlangıç Maliyeti

• Yüksek Öğrenme Eğrisi: DDD kavramları başlangıçta karmaşık gelebilir ve ekiplerin bu felsefeyi benimsemesi zaman alabilir.
• Başlangıç Maliyeti: İlk kurulum ve tasarım aşamaları, geleneksel yaklaşımlara göre daha fazla zaman ve efor gerektirebilir.
• Aşırı Mühendislik Riski: Basit projelerde DDD'nin tüm prensiplerini uygulamaya çalışmak, gereksiz karmaşıklığa yol açabilir.

Ne Zaman Kullanılmalı?

DDD, özellikle aşağıdaki durumlarda değerini gösterir:

• İş alanının karmaşık olduğu ve sürekli değişen gereksinimlere sahip olduğu projeler.
• İş uzmanları ve geliştiriciler arasında yakın işbirliğinin kritik olduğu durumlar.
• Uzun vadeli bakım ve sürdürülebilirlik gerektiren büyük ölçekli sistemler.

Gerçek Dünya Senaryolarında DDD

DDD, çeşitli sektörlerde ve uygulama türlerinde başarılı bir şekilde uygulanabilir.

E-ticaret Uygulaması Örneği

Bir e-ticaret uygulamasında, "Sipariş", "Ürün", "Müşteri", "Ödeme" gibi kavramlar farklı Sınırlı Bağlamlar olarak modellenebilir. Her bir bağlamın kendi içinde tutarlı bir modeli ve iş kuralları bulunur. Örneğin, "Sipariş Yönetimi" bağlamı, siparişin durum geçişlerini, indirim kurallarını ve iade süreçlerini yönetirken, "Stok Yönetimi" bağlamı ürünlerin stok seviyelerini ve rezerve işlemlerini ele alır. Bu bağlamlar, Etki Alanı Olayları aracılığıyla birbirleriyle etkileşime girer.

Finansal Sistem Örneği

Finansal sistemler, genellikle yüksek düzeyde karmaşık iş kuralları ve sıkı tutarlılık gereksinimleri içerir. "Hesap", "İşlem", "Bakiye", "Döviz Kuru" gibi kavramlar, DDD prensipleriyle modellenerek sistemin güvenilirliği ve doğruluğu artırılabilir. Örneğin, bir "Hesap" agregate'i, hesabın bakiyesini ve işlem geçmişini tutarlılık içinde yönetebilir.

Mikroservisler ve DDD

DDD ve mikroservis mimarisi birbirini mükemmel şekilde tamamlar. Her bir Sınırlı Bağlam, doğal olarak bir mikroservis sınırı olarak düşünülebilir. Bu, her mikroservisin kendi Etki Alanı Modelini ve Ortak Dilini geliştirmesine olanak tanır, böylece bağımsız olarak geliştirilebilir, dağıtılabilir ve ölçeklenebilir hale gelir.

Sonuç

O mülakat sorusu, benim için sadece bir iş görüşmesi değil, aynı zamanda yazılım mimarisine bakış açımı kökten değiştiren bir dönüm noktası oldu. Alan Odaklı Tasarım, teknik detaylara boğulmadan önce işin kendisini anlamanın ve bu anlayışı kodumuza yansıtmanın ne kadar kritik olduğunu gösterdi. DDD, karmaşık iş alanlarını yönetmek için sadece bir dizi teknik kalıp değil, aynı zamanda bir düşünce biçimi ve iş uzmanlarıyla daha derin bir işbirliği kültürü sunar. Bu felsefeyi benimsemek, daha esnek, sürdürülebilir ve iş değerine odaklı yazılımlar geliştirmemizi sağlar.

SSS (Sık Sorulan Sorular)

S: DDD her proje için uygun mudur?

C: Hayır, DDD özellikle karmaşık iş alanlarına sahip, uzun ömürlü ve değişime açık sistemler için en uygunudur. Basit CRUD uygulamaları veya çok küçük projeler için aşırı mühendislik olabilir.

S: Ortak Dil'i nasıl oluştururuz?

C: Ortak Dil, iş uzmanları ve geliştiricilerin sürekli iletişim ve işbirliği içinde olmasıyla zamanla gelişir. İş toplantılarında, tasarım tartışmalarında ve kod incelemelerinde kullanılan terimlerin tutarlı olmasına özen gösterilmelidir.

S: Agregalar neden bu kadar önemli?

C: Agregalar, veri tutarlılığını sağlamak için kritik öneme sahiptir. Bir agregate'in kök varlığı aracılığıyla erişilmesi, agregate içindeki tüm nesnelerin tek bir işlem birimi içinde tutarlı kalmasını garanti eder.

S: DDD, mikroservis mimarisiyle nasıl ilişkilidir?

C: DDD'deki Sınırlı Bağlamlar, mikroservislerin doğal sınırlarını belirlemek için harika bir yoldur. Her bir Sınırlı Bağlam, kendi Etki Alanı Modeline sahip bağımsız bir mikroservis olarak geliştirilebilir, bu da mikroservislerin avantajlarından (bağımsız dağıtım, ölçeklenebilirlik) tam olarak yararlanmayı sağlar.