Domain Driven Design

Domain 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. 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;

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.

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.