Domain Driven Design(DDD) Nedir ?
Bir önceki yazımda Mikroservisler nedir ? diye bir içerik oluşturmuştum. Bu yazımda Domain Driven Design yöntemini kullanarak yazılımımızı nasıl şekillendirebiliriz bundan bahsedeceğim.
Avantajları/Dezavantajları:
Nedir veya nasıl tasarlanır içerisinde neler barındırın konusuna girmeden önce avantaja ve dezavantajlarından bahsetmek istiyorum.
- Ddd ile büyük projeleri verimli şekilde parçalara ayırabilir ve ekiplerinizi başarılı şekilde yönetebilirsiniz.
- Bu yaklaşım sayesinde temiz, test edilebilir kod yazabiliriz. Ayrıca kodumuz kolayca değiştirilebilir hale gelir, yazılımı parçalara ayırdığımız için developerlar daha hızlı adapte olabilir.
Dezavantajları
- Proje gerçekten büyükse bu yaklaşım yarar sağlar, daha küçük projelerde kullandığımızda harcadığımız efor ve ortaya çıkan ürün bizi memnun etmeyebilir.
- Developer’lar domainin gereksinimlerini iyi anlamalı ve Domain Expert ile sürekli iletişim halinde kalmalı. Yapılacak işler bu yüzden daha fazla zaman alır ayrıca domain model hazırmalak başlangıçta çok fazla zaman alır ve burada iyi bir model çıkarmak için domainde uzman kişilere ihtiyaç duyarız.
Nedir:
DDD mikroservislerinizi oluşturmak için en uygun mimarilerden biridir. Bu yöntemi kullanmak için problemimizi iyi anlamalı ve parçalara doğru şekilde ayırmalıyız. Bir çoğumuz “Domain” terimini duymuşuzdur. Domain oluşturacağımız uygulamanın kapsamını belirler.
Örnek olarak E-Ticaret projeleri E-Ticaret domaininde, bankacılık uygulamaları bankacılık domainindedir. Martin Fowler DDD için bir domainin süreçleri ve kuralları hakkında zengin bir anlayışa sahip şekilde programlamaya odaklanan yazılım geliştirme yaklaşımı olduğunu söylüyor.
Örnek Proje:
DDD için ilk adımımız business domaini belirlemektir. Yani uygulamamız hangi domain altına alınabilir ve uygulamanın subdomainleri neler olabilir ? Bir çoğumuzun bildiği bir akış olduğu için yine e-ticaret projesini ele almak istiyorum.
Bounded Context:
Yukarıda gördüğünüz şema basit e-ticaret sitenin ihtiyaçlarının bulunduğu bir şema aslında problemimizin tanımlanmış hali.
Bounded Context belirlenmiş domain/sub-domainlerin çözümü alanıdır ve bu domainlerin sınırlarını belirler.Bu örnek için tek bir bounded context veya subdomainler için birden fazla bounded context oluşturabiliriz.
DDD ile domain model oluştururken Aggregate/Entity-Objects/Vale Objects,Services, Repositories, Events gibi kavramlar bulunmaktadır.
Aggregate/Entity-Objects :
Aggregate bounded contextlerimizin en temel elemanıdır. Örnek olarak Order bir aggregate iken ona bağlı OrderLineItems entity objecttir. Entity objectler root aggregate olmadan var olamazlar ancak bir identity değere sahiptirler. Bir aggregate birden fazla collectionları, entity objectleri içerir.DDD aggregate map, list gibi collection classlar ile karıştırılmamalıdır. “Aggregate” ifadesi farklı contextlerde(uml. vb) kullanılsa da, DDD de kullandığımızla aynı anlama gelmez.
Value Objects:
Value objectler bir identifier değildir yani identity değerleri yoktur. Order aggregate List içeriyor demiştik burada OrderLineItem bir entity ancak Order kendi içerisinde OrderDetail diye bir classda içerebilir.Burada dikkat etmemiz gereken OrderDetail’in kendi içinde identity değeri yani(Id) gibi bir değeri yoktur.Bu ve buna benzer şekilde tanımlayabileceğimiz DTO’lar(Data transfer object) value object olarak karşımıza çıkar. Value Object’ler birden fazla field değerlerinin birleşmesi ile farklılık kazanabilirler.
Service:
Servisler temel olarak iş kuralı tanımının object olarak ifade edilmesidir. Agrregate’lere Bounded Context’lerin sınırlarına göre Business Logic’leri çalıştırmak için yardım eder. Bir başka deyişle içerisinde işlevler mevcut ancak başka bir object ile varlık ilişkisi yoksa bunlara servis diyebiliriz.
Repository:
Git Repositorylerin alışık olduğumuz dışında,DDD’de Repository, Bounded Context içinde bulunan aggregate/entitylerin tüm operasyonlarının durumlarını tutan yapılardır. CRUD işlemlerini Repository aracılığıyla yapıyoruz. Mesela müşteriye ait siparişlerin getirilmesi veya sipariş durumun güncellenmesi vs. Repository direk database işlemlerinde kullanılıyor.
Events:
E-Ticaret uygulamamızın subdomainlerine ayırıp her bir subdomaini bir bounded context olarak düşünelim. Bu durumda bounded contextler arasında iletişim kurmamız gerekir. Örnek olarak sipariş oluşturulduğunda Customer’a ait bounded context bu işlemden haberdar olma ihtiyacı duyar bunun için OrderCreated diye bir event tetikleyebiliriz. Sonuç olarak mikroservislerimiz arasındaki haberleşmeyi eventlar aracılığıyla yapıyoruz diyebiliriz.
Sonuç olarak Domain Driven Design sadece mikroservis mimarisinde kullanılıyor söyleyemesek de bu servisleri ayırabilmemiz ve maintain etmemiz için uygun bir yapı sağlamaktadır.
Kaynakça:
https://martinfowler.com/bliki/DomainDrivenDesign.html
https://airbrake.io/blog/software-design/domain-driven-design
