Domain Driven Design (DDD), bir yazılım tasarım yaklaşımıdır ve yazılım projelerindeki karmaşıklığı azaltmaya yöneliktir. Bu yaklaşım, problemleri, çözümleri ve yazılım bileşenlerini bir arada ele alarak yazılım tasarımını kavramsal bir modele dayandırır.
DDD, özellikle büyük ve karmaşık yazılım projelerinde kullanılan bir yaklaşımdır. Bu yaklaşım, bir projenin anahtar bileşenlerinin anlaşılmasına ve bunların birbirleriyle nasıl etkileşimde bulunduklarına odaklanır. Bu bileşenlerin etkileşimleri, proje sorunlarının çözülmesinde yardımcı olan bir dizi anlaşılır ve uygulanabilir kavramlar kullanılarak modellenir.
DDD'nin ana fikri, yazılımın temel iş süreçlerinin gerçek dünya kavramlarına ve mantığına dayandırılmasıdır. Bu yaklaşım, geliştiricilerin, müşterilerin ihtiyaçlarını ve problemlerini daha iyi anlamalarına ve yazılımın doğru bir şekilde tasarlanmasına yardımcı olur.
DDD, üç temel bileşen üzerine kuruludur:
Dil: Projenin başarısı, tüm paydaşların projeyi anlama ve tanımlama şekline bağlıdır. Bu nedenle, DDD, projeler için bir ortak dil oluşturulmasına odaklanır.
Modelleme: Yazılımın geliştirilmesi, anahtar iş süreçlerinin modellenmesiyle başlar. Bu modeller, gerçek dünya kavramlarına dayandırılır ve yazılımın karmaşıklığını azaltır.
Kontrol: DDD, yazılımın tasarımı ve geliştirilmesi sırasında kontrolün elden bırakılmamasını sağlar. Bu, yazılımın daha az hata ve sorunla çıktısı alınmasına yardımcı olur.
Sonuç olarak, DDD, büyük ve karmaşık yazılım projelerinde kullanılan bir yazılım tasarım yaklaşımıdır. Bu yaklaşım, yazılımın temel iş süreçlerinin gerçek dünya kavramlarına ve mantığına dayandırılmasıyla başlar ve bir ortak dil oluşturulmasına, modellenmesine ve kontrol edilmesine odaklanır.
Daha anlasilir olmasi icin Örneğimiz, bir e-ticaret platformu olabilir.
İlk olarak, e-ticaret platformu için bir dil oluşturmalıyız. Örneğin, müşterilerin "sipariş" verdiklerini ve siparişlerin "ürünler" içerdiğini söyleyebiliriz. Ayrıca, ürünlerin "stok" durumları olacak ve müşterilerin "ödeme" işlemi yapacaklarını kabul edebiliriz.
Daha sonra, e-ticaret platformunun anahtar bileşenlerini modellendirmeliyiz. Örneğin, "Müşteri" ve "Sipariş" sınıflarını oluşturabiliriz. Siparişler, bir veya daha fazla ürünü içerir ve ürünler, bir stok sayısı ve fiyatla ilişkilendirilir. Ayrıca, ödeme işlemleri, bir siparişin tamamlanması için gereklidir ve ödeme hizmetleri, ödeme işleminin gerçekleştirildiği yerleri temsil eder.
Son olarak, kontrol sağlamalıyız. Örneğin, stok düzeylerinin yeterli olduğundan emin olmalıyız. Ayrıca, siparişlerin tamamlandığından ve ödemelerin doğru şekilde yapıldığından emin olmalıyız.
Bu örnek, e-ticaret platformunun bazı temel bileşenlerini DDD'nin temel prensiplerine göre modellendirir. Bu, yazılımın tasarımının daha anlaşılır ve yönetilebilir olmasını sağlar.
başka bir örnek vererek DDD'yi daha iyi anlatmaya çalışabilirim. Örneğimiz, bir banka hesabı yönetim uygulaması olabilir.
İlk olarak, banka hesabı yönetim uygulaması için bir dil oluşturmalıyız. Örneğin, hesap sahiplerinin "hesap" açabileceklerini ve hesapların "bakiye" içereceğini söyleyebiliriz. Ayrıca, hesap sahiplerinin "para transferi" yapabileceklerini ve "fatura ödeme" işlemi gerçekleştirebileceklerini kabul edebiliriz.
Daha sonra, banka hesabı yönetim uygulamasının anahtar bileşenlerini modellendirmeliyiz. Örneğin, "Hesap" ve "Müşteri" sınıflarını oluşturabiliriz. Hesaplar, bir bakiyeye sahiptir ve para transferleri, bir hesap sahibinden diğerine gerçekleştirilebilir. Fatura ödemeleri de bir hesap sahibi tarafından yapılabilir ve fatura ödeme hizmetleri, ödemelerin yapıldığı yerleri temsil eder.
Son olarak, kontrol sağlamalıyız. Örneğin, hesap bakiyelerinin yeterli olduğundan emin olmalıyız. Ayrıca, para transferlerinin doğru şekilde gerçekleştirildiğinden ve fatura ödemelerinin tamamlandığından emin olmalıyız.
Bu örnek, banka hesabı yönetim uygulamasının bazı temel bileşenlerini DDD'nin temel prensiplerine göre modellendirir. Bu yaklaşım, yazılımın daha anlaşılır ve yönetilebilir olmasını sağlar.
birkaç sınıfın ve aralarındaki ilişkilerin gösterildiği basit bir UML diagramı
+-------------+ +---------------+
| Hesap | | Musteri |
+-------------+ +---------------+
| bakiye |1 * | adi |
| | | soyadi |
+-------------+ +---------------+
|1 |
| |
| |
+------------------+ +----------------------+
| ParaTransferi | | FaturaOdeme |
+------------------+ +----------------------+
| tutar | | tutar |
| gonderenHesapIdi | | alanHesapIdi |
| alanHesapIdi | | odemeHizmetiId |
+------------------+ +----------------------+
* |
\ |
\ |
+----------------------+
| OdemeHizmeti |
+----------------------+
| odemeHizmetiAdi |
+----------------------+
Bu UML diyagramında, "Hesap" ve "Müşteri" sınıfları arasındaki bir-çok ilişki gösterilmektedir. "Hesap" sınıfı, bir bakiyeye sahip olduğu için "bakiye" niteliğine sahiptir. "Müşteri" sınıfı, "adi" ve "soyadi" gibi özellikleri içerir.
Daha sonra, "ParaTransferi" ve "FaturaOdeme" sınıfları arasındaki ilişkiler gösterilir. Her iki sınıfın da bir "tutar" niteliği vardır ve "gonderenHesapIdi" ve "alanHesapIdi" gibi bağlantıları vardır. Ayrıca, "FaturaOdeme" sınıfının bir "odemeHizmetiId" niteliği vardır ve bu, "OdemeHizmeti" sınıfına bağlanır.
Sonuç olarak, bu UML diyagramı, bir banka hesabı yönetim uygulamasının DDD prensiplerine uygun olarak modellenmesine bir örnek teşkil eder.