Domain Driven Design (DDD) Nedir? (Bölüm: 1)

post-thumb

Domain-Driven Design (DDD), karmaşık yazılım projelerini yönetilebilir parçalara bölerek, iş problemlerine odaklanmayı amaçlayan bir yazılım geliştirme yaklaşımıdır. Eric Evans tarafından popülerleştirilmiştir ve iş problemlerini anlamak ve yazılımı buna göre şekillendirmek için çeşitli teknikler ve kavramlar sunar. DDD, özellikle büyük ve karmaşık projelerde, iş kurallarını yazılım tasarımının merkezine alarak başarılı sonuçlar elde etmeyi hedefler.

DDD'nin Temel Kavramları

1. Domain (Alan)

Domain, yazılımın çözmeye çalıştığı iş problemini tanımlar. Örneğin, bir e-ticaret sistemi geliştiriyorsanız, "domain"iniz e-ticaretin kendisi, yani sipariş yönetimi, müşteri ilişkileri, envanter yönetimi gibi konular olacaktır.

Örnek: Bir online alışveriş sitesinde, domain şunları içerebilir:

  • Sipariş Yönetimi: Müşterilerin sipariş vermesi, siparişlerin işlenmesi ve gönderilmesi.
  • Envanter Yönetimi: Ürün stoklarının takibi ve yönetimi.
  • Müşteri İlişkileri: Müşteri bilgileri, sipariş geçmişi ve müşteri hizmetleri.

2. Entity (Varlık)

Entity, bir domain içinde tanımlanan ve bir kimlik (ID) ile ayrıştırılan nesneleri temsil eder. Entity'ler, belirli bir kimlikleri olduğu için zaman içinde değişebilirler ama kimlikleri sabit kalır.

Örnek:

  • Müşteri: Her müşterinin benzersiz bir kimliği (ID) vardır. Adı, adresi gibi özellikleri zamanla değişebilir, ancak kimliği aynı kalır.
  • Sipariş: Siparişin bir kimliği vardır ve zamanla siparişin durumu değişebilir (örneğin, yeni, işleniyor, gönderildi).

3. Value Object (Değer Nesnesi)

Value Object, bir kimliği olmayan nesnelerdir. Value Object'ler tamamen eşit olduğunda aynı kabul edilirler. Genellikle, bir Entity'nin özelliklerini tanımlamak için kullanılırlar.

Örnek:

  • Adres: Bir adresin belirli bir kimliği yoktur. İki farklı müşterinin adresleri aynı olabilir ve bu durumda adresler aynıdır.
  • Para Birimi: Bir para birimi miktarı bir kimliğe sahip değildir, sadece değeri önemlidir.

4. Aggregate (Küme)

Aggregate, bir veya daha fazla Entity ve/veya Value Object'in bir araya gelerek oluşturduğu, tutarlı bir iş birimi olarak hareket eden gruptur. Aggregate'in bir kök Entity'si (Root) vardır ve bu root üzerinden aggregate yönetilir.

Örnek:

  • Sipariş (Order) Aggregate: Sipariş root entity'si, siparişin öğeleri (ürünler), toplam tutar gibi bilgileri içerir. Sipariş üzerinde yapılan tüm işlemler bu root üzerinden yönetilir.

5. Repository (Depo)

Repository, Entity ve Aggregate'leri kalıcı depolama ortamından alma veya depolama işlevini yerine getirir. Repository'ler, genellikle bir veri tabanı gibi altyapı detaylarını soyutlayarak, domain nesneleri ile bu altyapı arasında bir köprü görevi görür.

Örnek:

  • Sipariş Deposu (Order Repository): Siparişlerin veri tabanında nasıl saklandığını veya getirildiğini yönetir.

6. Service (Hizmet)

Service, bir Entity veya Value Object'in doğrudan yapamayacağı bir işi gerçekleştiren domain lojik birimidir. Servisler, genellikle birden fazla Entity'yi içeren veya daha karmaşık iş kurallarını uygulayan işlemleri yürütür.

Örnek:

  • Ödeme Hizmeti (Payment Service): Bir siparişin ödemesini işlemek, birden fazla Entity (Sipariş, Müşteri, Ödeme) üzerinde işlem yapmayı gerektirebilir.

7. Domain Event (Alan Olayı)

Domain Event, domain içinde önemli bir olay meydana geldiğinde (örneğin, bir siparişin tamamlanması) tetiklenen ve bu olayla ilgili bilgileri içerir. Domain Event'ler, sistemdeki diğer parçaların bu olayları dinlemesini ve buna göre tepki vermesini sağlar.

Örnek:

  • Sipariş Tamamlandı Olayı (Order Completed Event): Sipariş tamamlandığında tetiklenir ve sistemdeki diğer modüller bu olaya göre (örneğin, müşteri bilgilendirme) aksiyon alır.

DDD'nin Örnek Kullanımı

Bir e-ticaret platformunda DDD uyguladığımızı düşünelim:

  1. Domain: E-ticaret platformu, satış, sipariş yönetimi, müşteri hizmetleri gibi domain'lerden oluşur.

  2. Entity: Sipariş (Order), Müşteri (Customer), Ürün (Product) gibi Entity'ler tanımlanır.

  3. Value Object: Adres (Address), Para Birimi (Currency) gibi kimliksiz nesneler tanımlanır.

  4. Aggregate: Sipariş aggregate'i, siparişin root entity'si ile birlikte, sipariş öğelerini ve ödeme bilgilerini içerir.

  5. Repository: Sipariş Repository'si, siparişleri veri tabanından alır ve kaydeder.

  6. Service: Ödeme Servisi, bir siparişin ödemesini işlemek için kullanılır.

  7. Domain Event: Sipariş tamamlandığında bir Domain Event tetiklenir ve bu olayla diğer modüller (örneğin, envanter yönetimi) bilgilendirilir.

DDD'nin Faydaları

  • İş Odaklılık: DDD, yazılımın iş kurallarını ve ihtiyaçlarını merkez alır, bu sayede yazılımın iş problemlerini çözme yeteneği artar.
  • Modülerlik ve Bakım Kolaylığı: DDD, domain'leri ve ilişkili nesneleri modüllere ayırır, bu da kodun daha kolay yönetilmesini ve genişletilmesini sağlar.
  • Uygulama Esnekliği: DDD, yazılımın zamanla evrilmesini kolaylaştırır çünkü değişiklikler domain'e özgüdür ve genellikle diğer modülleri etkilemez.

DDD'nin Zorlukları

  • Öğrenme Eğrisi: DDD'nin kavramlarını anlamak ve uygulamak, özellikle küçük ve basit projelerde gereksiz karmaşıklığa yol açabilir.
  • Büyük Projeler İçin Uygun: DDD, daha çok büyük ve karmaşık projelerde fayda sağlar; küçük projelerde gereksiz görülebilir.

Sonuç olarak, Domain-Driven Design, karmaşık yazılım projelerinde iş ihtiyaçlarına odaklanarak yazılımın daha etkili ve sürdürülebilir bir şekilde geliştirilmesini sağlar. Bu yaklaşım, özellikle karmaşık iş kurallarına sahip projelerde güçlü ve esnek bir yapı sunar.