Kitap 09 · Yazılım MimarisiSayfa 12 / 48

Domain-Driven Design

Alan Odaklı Tasarım

Türkçe karşılığı: etki alanı odaklı tasarım
Okunuşu: domeyn drivın dizayn

Günlük kullanımda çoğunlukla İngilizcesi tercih edilir.

Güncellendi 30 Eylül 20262 dk okuma

Kısaca

Domain-driven design, kodu iş alanına yakından modelleyen ve alan uzmanlarıyla aynı dili kullanan bir yazılım geliştirme yaklaşımıdır.

Domain-driven design nedir?

Domain-driven design ya da kısaca DDD, Eric Evans'ın aynı adlı 2003 tarihli kitabında ortaya koyduğu bir yaklaşımdır. Çoğu yazılımda en zor kısmın, alan (domain) denen iş problemini anlamak olduğunu savunur; bu yüzden geliştiricilerin alan uzmanlarıyla yakın çalışması ve kodu işin gerçekte nasıl yürüdüğüne göre şekillendirmesi gerekir. Alan; nakliye lojistiği, sigorta hasarları ya da çevrimiçi bankacılık olabilir.

Temel uygulamalardan biri ubiquitous language'dir (ortak dil): geliştiricilerin ve uzmanların toplantılarda, belgelerde ve kodun kendisinde kullandığı ortak bir söz dağarcığı. İş tarafı bir sevkiyatın gönderilmesinden söz ediyorsa kodda genel bir updateStatus fonksiyonu değil, dispatch() metodu olan bir Shipment sınıfı bulunur. Büyük alanlar, kendi tutarlı modeli ve diline sahip bölgeler olan bounded context'lere (sınırlı bağlam) bölünür; örneğin müşteri, satış ekibi için destek ekibinden farklı bir anlama gelir.

DDD modele yönelik yapı taşları da sunar. Entity'ler, ID'li bir sipariş gibi zaman içinde kalıcı bir kimliği olan nesnelerdir; value object'ler, bir para tutarı gibi yalnızca değerleriyle tanımlanır; aggregate'ler ise birlikte tutarlı kalması gereken ve yalnızca tek bir kök nesne aracılığıyla değiştirilen nesne kümeleridir. Domain event'ler OrderShipped gibi olan önemli şeyleri kaydeder.

Bir mimarın binayı tasarlamadan önce hastanenin doktor ve hemşireleriyle vakit geçirmesi, yerleşimin onların gerçek çalışma biçimine uyması için iyi bir benzetmedir. DDD sıklıkla mikroservislerle karıştırılır: bounded context'ler servis sınırlarının nereye çizileceğine karar vermek için yararlı bir yoldur, ancak DDD modelleme ile ilgilidir ve monolitte de aynı ölçüde iyi çalışır. Karmaşık iş mantığında karşılığını verir; basit CRUD uygulamaları için genellikle fazla ağırdır.

Önemli noktalar

DDD kodu iş alanına ve uzmanlarının bilgisine göre şekillendirir.
Ortak dil, iş terimlerini ve kod adlarını aynı tutar.
Bounded context'ler büyük bir alanı kendi modeli olan bölgelere ayırır.
Entity'ler, value object'ler ve aggregate'ler temel yapı taşlarıdır.
Karmaşık iş mantığında işe yarar, basit CRUD uygulamalarında değil.

Örnek

TypeScript'te bir value object ve bir entitytypescript

// Value object: defined only by its values and never changed after creation
class Money {
  constructor(readonly amount: number, readonly currency: string) {}
}

// Entity and aggregate root: has an identity and protects its own rules
class Order {
  private status: "draft" | "placed" | "shipped" = "draft";
  constructor(readonly id: string, readonly total: Money) {}

  ship() {
    if (this.status !== "placed") throw new Error("Only placed orders can ship");
    this.status = "shipped"; // named in the business's own language
  }
}

Sık sorulan sorular

DDD'de bounded context nedir?

Bounded context, belirli bir alan modelinin ve terimlerinin tek bir tutarlı anlama sahip olduğu net bir sınırdır. Faturalama ve nakliye gibi farklı bağlamların her biri, müşteri gibi aynı gerçek dünya kavramının kendi modeline sahip olabilir.

Domain-driven design ile mikroservisler aynı şey mi?

Hayır. DDD iş mantığını modelleme yaklaşımıdır; mikroservisler ise bir sistemi ayrı servisler olarak dağıtma yoludur. Bounded context'ler mikroservis sınırlarına karar vermek için sık kullanılır, ancak DDD bir monolitin içinde de aynı ölçüde iyi çalışır.

Domain-driven design ne zaman kullanılmalı?

DDD en çok finans, lojistik ya da sağlık gibi iş kurallarının karmaşık olduğu ve sık değiştiği durumlarda değerlidir. Çoğunlukla veri okuyup yazan basit CRUD uygulamalarında ise uygulamaları genellikle sağladığı faydadan fazla yük getirir.

İlgili sayfalar

Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin