Tag Archives: Domain Driven Design

Domain Driven Design ne zaman uygulanmalıdır

28 Şub

Bir önceki yazının konusu Domain Driven Design(DDD) konulu bir kitap tanıtımıydı. Bu yazıda DDD yaklaşımının hangi durumlarda kullanılması gerektiğini bir kaç cümleyle özetlemeye çalışacağım. Yaklaşımın özelliklerini daha ilerki yazılarda fırsat buldukça anlatmaya çalışacağım.

Domain Driven Desing(DDD) kavramı karmaşık problemlerin küçük parçalara bölünerek ele alınmasını amaçlayan bir yaklaşım tarzıdır. Karmaşık problemlerin parçalara ayrılması da aslında çözülmesi gereken bir problemdir. Taleplerin alınması, iş kurallarının
belirlenmesi ve taleplerin yazılım terminolojisine uygun hale getirilmesi sürecin başlıca gereksinimlerdir. DDD birbiriyle ilişkili iş kurallarının ele alındığı bir yöntem olması sebebiyle çok geniş kapsamlı kurumsal yazılımlar geliştirirken uygulanması gereken bir yaklaşımdır. Örneğin hava yolu rezervasyon sistemleri, e-ticaret uygulamaları, bir devlet kurumu bünyesindeki otomasyon sistemleri şeklinde örnekler verilebilir. İş kurallarının sık olarak değiştiği ve taleplerin sürekli artacağı öngörülen yazılım sistemleri için yazılımın geleceğine aydınlık bir altyapı tasarlamak amacıyla uygulanabilir. Örneğin kanun ve yönetmeliklerin çok sık değiştiği  kurumlarda geliştirilen yazılımları gibi. Ancak karmaşık iş kuralları olmayan basit sistemler için DDD uygulamak uygun olmaz. Örneğin blog sayfaları veya ürün tanıtım amaçlı web projeleri için DDD uygulamak uygun değildir. Bu tür uygulamalar sadece  veri erişimi ve görüntülemesi amaçlanmıştır. Bu tür uygulamaları veriyi kullanıcı ara yüzüne direk aktaran teknikler ile geliştirmek mantıklı bir seçim olacaktır. Aksi taktirde  basit olan bir çözümü, karmaşık hale getirmiş oluruz.

Kitap – Domain Driven Design

27 Şub
Domain Driven Design
Domain Driven Design

Kitap tavsiye kategorisinin bu bölümünde Domain Driven Desing Tackling Complexity in the Heart of Software isimli kitaptan bahsedeceğiz.

Kitap Eric Evans tarafından kaleme alınmış olup dili ingilizcedir. Basılı kitabı buradan temin etmek mümkündür.

Kitapta karmaşık yapıdaki yazılımlar geliştirirken nasıl bir yazılım tasarımının uygulanması gerektiği konusu ele alınmıştır. Bu tasarım Domain Driven Design diye adlandırılmıştır.

Domain Driven Design yaklaşımı, problemin çözümünün domain diye adlandırılan bir alanda yapılması esasına dayanmaktadır. Burada problem, bir hava yolları rezervasyon sistemi veya bir e-ticaret sistemi tasarlamak olabilir. Bu noktada müşteri ve programcı karşı karşıya gelmektedir. Müşteri gereksinimleri, Domain Expert denen kişiler tarafından iyi bir şekilde tespit edilerek programcının anlayacağı bir şekle dönüştürülür. Programcı ve Müşteri arasında  sağlıklı bir iletişimin kurulabilmesi için Ubiquitous Language diye adlandırılan ortak bir dil oluşturulur. Gerekli iletişim sağlandıktan sonra sistem programcılar tarafından geliştirilmeye başlar.

Domain Driven Design yaklaşımı bize genel olarak dört temel katman üzerine inşaa önerir. Bunlar:

  • Presentation layer
  • Application layer
  • Domain layer
  • Infrastructure layer

Problemin çözümü için gerekli model Domain Layer üzerinde kurulur. Diğer katmanlar sunum ve iletişim katmanları olarak kullanılır.

Eric Evans’a göre Domain-Driven Design yaklaşımı, yazılım dünyasının popüler konularından birisi oldu ve kapsamlı yazılım projelerinde kullanılıp faydası görüldükçe yaygınlaşacak. Bunun yanında her projede Domain Driven Design yaklaşımını uygulamak yanlış olur. Sadece gerektiğinde kullanmak uygun olacaktır.

Domain Driven Design Servisleri

11 Oca

Bir domain model için en önemli yapı taşlarından biri servislerdir. Servisler, modele ait Entity ve Value nesnelerinin yapısına aykırı davranışları kendi bünyesinde taşıması için tasarlanırlar. Böylelikle Entity ve Value nesnelerinin vazifesi olmayan işleri yüklenmesini önlemiş olurlar.

Eric Evans‘a göre iyi tanımlanmış bir servisin belli karakteristik özellikleri vardır. Bunlar:

  • Domain nesnelerinin doğal bir parçası olmayan işlemleri yönetir.
  • Domain modelin diğer elemanları açısından Interface’ler tanımlanır.
  • Servis işlemler belli bir yerde tanımlanmak zorunda değildir.

Servisler test edilebilir olması ve birbirine bağlı işlemleri belirleyici olması açısından mutlaka bir  Interface çatısı altında bulunmalıdır. Interface’ler servislerin sözleşmeleridirler.

Servisler Application, Domain, Infrastructure gibi birçok katmanda bulunabilir.

Infrastructure servisleri IEmailSernder gibi dış kaynaklarla iletişimi sağlayan servislerdir. Dış kaynaklar  dosya sistemleri, SMTP, veritabanı, SMS gibi yapılar olabilir. Domain katmanı bir bildirimin kullanıcılara nasıl iletildiği ile ilgilenmez, sadece iç süreci tamamlar ve bir olayı(Event) tetikler.

Domain servisleri, küçük parçalar arasında üst seviye işlevselliği sağlayan kooordinatör vazifesindedir.  Örneğin sipariş işlemi için OrderProcessor servisi, para transferi için FundTransferService gibi. Domain  servisleri model için çok önemli olduğundan isimleri ve kullanımları Ubiquitous Language diye adlandırılan  ve kavramsal bir ifade olan domain dilinin bir parçası olmalıdır. Anlamları ve sorumlulukları müşteri ve  domain uzmanı tarafında tutarlı ve mantıklı olmalıdır.

Application servisleri dış ortama açılan servislerdir. Dış ortamdakiler bizim Entity nesnelerimizle doğrudan  iletişime geçemez. Fakat bunları temsil eden nesnelerle iletişime geçebilir. Katmanlar arasında iletişimi  doğrudan domain nesneleri ile yaparsak diğer katmanlar domain yapımız hakkında çok fazla bilgi sahibi olurlar. Application servisleri dış ortamdan gelentalepleri mesaj şeklinde model içindeki süreçlere aktarır. Bu noktada  Messaging Pattern diye adlandırılan yeni bir kavram karşımıza çıkıyor. Messaging Pattern Application  servislerinin kuralı gibidir. Dış ortamdan taleper mesaj olarak alınır ve iç süreç tamamlandıktan sonra sonuç  dış ortama servisler aracılığı ile mesaj olarak verilir. Application servisleri herhangi biriş kuralı içermezler. İş kuralları Domain katmanı için yürütülür.

Tasarıma başlarken genellikle öncelikle Domain ve Applicaiton servislerin oluşturlması ve kullanıcılara sunulacak olan Interface tiplerinin belirlenmesi daha sonra da Test Driven Development ile dış davranışların test edilmesi uygun olacaktır. Kullanıcı bakış açısından senaryoları oluşturup test etmek bize büyük katkılar sağlar. Çünkü yazdığımız kod sonuçta bir kullanıcıya sunulacaktır.

Özet

Domain Service: Domain nesnelerinin doğal yapısına sığmayan işletme mantığını kapsar. Bunlar CRUD işlemleri değildir. CRUD işelmeri repository bünyesinde gelişir.

Application Service: Sistem dışı kullanıcılar için oluşturulur. Örneğin Web servisleri veya Web arayüzleri bu servislerle haberleşirler. Kullanıcılara sunulan CRUD işlemleri burada tanımlanabilir.

Infrastructure Service: Dış kaynaklarla yapılan iletişimler için oluşturulur. (File, SMS, SMTP, MSMQ).

Kaynak:

  • Eric Evans, Domain Driven Design Tackling Complexity in The Heart of Software
  • http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/