Son Yazılar

Domain Driven Design

Domain Driven Design (DDD) Nedir ?

Domain Driven Design, projemizdeki karmaşıklığı çözmemize ve yönetilebilmesine yardımcı olan, ayrıca projemizi sürdürülebilir kılmamıza imkan veren bir yaklaşımdır. İlk olarak 2013 yılında yayımlanan Domain-Driven Design adlı kitapta Eric Evans tarafından belirtilmiştir. Projemizdeki karmaşıklık aslında projemizde yer alan bir çok business kurallarıdır.

Domain Driven Design’ın Kullanım Amaçları

Sepetten sorumlu bir microservice, fatura işlemlerinden sorumlu bir microservice ve buna benzer yapılardan oluşan servislerde çok fazla business kuralları olabileceği için buradaki karmaşıklığı yönetebilmek ve kodlarımızı sürdürülebilir kılmak için bu yaklaşımı kullanabiliriz.

Ancak bir blog sitesi vb. yapılarda çok fazla business kuralı yer almayacağı için DDD yaklaşımını kullanmak gereksizdir. Çünkü makale ekleme, makaleleri listeleme vb. CRUD işlemler gerçekleştiği için çok fazla karmaşık bir yapı mevcut değildir ve buna rağmen DDD kullanırsanız kodunuzu aslında gereksiz yere karmaşık bir hale getireceksiniz. Ama bir fatura oluşturmasını düşünürsek o faturanın oluşturulma aşamasında çok fazla business kural gerçekleştirilmiş olabilir ve buradaki işlemlerin karmaşıklığından kurtulabilmek için DDD doğru bir yaklaşım olacaktır. 

Ubiquitous Language

Türkçeye çevirirsek; Her yerde bulunan ortak bir dil gibi düşünebiliriz. O halde bunun önemini bir senaryo üzerinden değerlendirelim; 

Ubiquitous Language

Bir fatura oluşturma servisi düşünelim. Yukarıdaki resimdeki turuncu kısmı bir masa olarak düşünürsek; solda bulunan Domain Expert, fatura oluşturma ve fatura işlemlerinin yapılması hakkında bilgi sahibi olan uzman kişi ve sağ taraftaki ise bu işin yazılım kısmında nasıl yapılması gerektiğini bilen uzman kişi. DDD’ye göre bu iki arkadaş ortak dili kullanmalı. Yani örnek verecek olursak; Domain Expert’teki kişinin fiş diye adlandırdığı şeye Development’taki kişi makbuz dememeli. Her ikiside ortak bir dili kullanmalı.

Bounded Context

Bir ana domain içerisinde (e-ticaret gibi) yer alan parçaları mantıksal olarak grupladığımız ve ilgi alanlarına göre bir araya getirdiğimiz yapılardır. Bir e-ticaret sistemi üzerinden gidecek olursak;

E-Ticaret sisteminde;

  • Stok yönetimi
  • Sipariş yönetimi
  • Ödeme yöntemi
  • Ürün yönetimi
  • Müşteri yönetimi

gibi birbiriyle ilişkili alanlar vardır. Bu birbiriyle ilişkili alanların her birini bounded context olarak adlandırırız.

Bounded Context Mimari Yapısı

Yapı olarak Onion Architecture yapısı kullanılır. Aşağıdaki resimde her halkayı bir katman olarak düşünürüz ve bu katmanların birbirleri ile haberleşmesi içten dışa doğrudur.

Bounded Context Mimari Yapısı

Entity :  Kendisine ait bir unique değeri olan yapılardır.

Value Object :  Kendisine ait bir unique değeri olmayan yapılardır.

Aggregate Root :  Birbiriyle alakalı entity lerin bir arada bulunmasıdır.

Domain Driven Design
YAZIYI PAYLAŞ
5 1 Oy
Article Rating
Abone ol
Bildir
guest
1 Yorum
En Eskiler
En Yeniler En Çok Oylanan
Satır İçi Geri Bildirimler
Tüm Yorumları Görüntüle
Selin
Selin
2 ay önce

Güzel bir girişti. Bazı kavramlara aşina değildi anlamama yardımcı oldu. Ancak bounded context’te bazı kavramlar açıklanmamaış. devamı varsa ya da yazarsanız harika olur. Elinize sağlık.