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/

TDD Sizi Yavaşlatmaz

19 Ağu

TDD(Test Driven Development) yaklaşımı için ortaya atılan eleştirilerden biri kod geliştirmeyi yavaşlattığı yönündedir.  TDD yaklaşımı, yöntem olarak şelale(waterfal) tarzı yaklaşımdan çok farklıdır. Dolayısıyla şelale tarzı geliştirmeyi bırakmak demek eski alışkanlıklardan vazgeçmek demektir. Ben TDD yaklaşımını ilk uygulamaya başladığımda, kendimi sanki sağ ayakla futbol oynarken sol ayakla oynamaya alıştıran oyuncu gibi hissetim. Çünkü alışkanlığımın tersi bir durum söz konusuydu. Önce kodu yazıp sonra test etmeye alışmışken, önce testin yazılıp sonra kodun üretildiği bir ortamda buldum kendimi.

Eski yöntemde yazdığım kodu test etmek için kullanıcı arayüzü (form, console) hazırlamam gerekirdi. Bu da hayli bir zaman kaybı demekti. Test edilecek sınıfa ait üyeleri test etmek için kullanıcı arayüz hazırlamak zahmetli ve uzun süren bir işlemdir. Test arayüzünü hazırladıktan sonra, ilgili forma kritik test parametrelerini elle tekrar tekrar girip denemek gerekir. Örneğin matematiksel bir fonksiyonu hesaplayan bir metodu test etmek için önce parametrenin sıfırdan küçük, sonra sıfır, sonra sıfırdan büyük olması durumunu sürekli test etmek gerekebilir. Metodun özellikleri arttıkça test sayısı da artar. Arada bir hata alırız ve hatayı düzelttikten sonra testleri tekrar yapmamız gerekir. Test senaryoları arttıkça, elle yapılan işlem sayısı da doğru orantılı olarak artar.

Testlerin elle yapılmasının gereksiz yere zaman harcadığını fark eden yazılımcılar, test sürecinin otomatik işletilmesi gerektiğine karar vermiştir. Tek bir tuşa basarak yazılımın bütün testlerini çalıştırıp kısa bir süre içinde geliştiriciye sonucu veren araçlar geliştirilmiştir. Bu araçlar sayesinde testler hızlı bir şekilde yapılmaktadır.

TDD yaklaşımı testlerin otomatik bir şekilde çalıştırılması anlamına gelmez. Çalışan koddan önce testin yazılması anlamına gelir. Test öncelikli(Test First) yaklaşım olarak da adlandırılır. TDD yaklaşımında kodu yazan kişi, kodunu kullanıcı gözü ile görerek geliştirmeye çalışır. Bu yazdığım API veya Framework’ün kullanıcısı olsam nasıl bir sınıf ve metod yazardım diye düşündürür geliştiriciyi. Bu geliştiriciyi yavaşlatmaz. Kodlama yapan kişinin koduna olan güvenini arttırır. Kişi geliştirdiği koda hükmetmeyi öğrenir. Testler başarıyla gerçekleştiğinde kişi güvenilir bir kod ürettiğini bilir.

TDD yaklaşımında uzmanlar hızdan ziyade kaliteli ürün geliştirmenin önemli olduğuna vurgu yapmaktadır. Yani müşteri sizin hangi yöntemlerle geliştirme yaptığınıza değil ortada düzgün çalışan bir uygulamanızın olup olmadığına bakar. Puanınızı buna göre alırsınız. Kötü uygulamalar demek hata oranı yüksek, kullanımı zor ve zaman kaybettiren uygulamalar demektir. Kötü uygulamaların üzerine yeni özelliklerin eklenmesi veya mevcut özelliklerinin değiştirilmesi zordur. Test edilmeden hızlı bir şekilde geliştirip teslim edilen uygulamaların bakımı ve ilerletilmesi sonraki aşamalarda zaman kaybettirici olacaktır. Değişimin zamanında yapılamaması da müşteri memnuniyetini önemli ölçüde azaltacaktır. Hiçbir müşteri binlerce satır boş koda para harcamak istemez. Binlerce satır kod yazmış olmak kişiyi iyi bir geliştirici yapmaz. (Ancak bazı kariyer ilanlarında aranan programcı kriterleri arasında “10000 bin satır kod yazmış olmak” şeklinde komik maddelere rastlarız)

TDD ile geliştirme yaparken çalıştırdığınız testlerin sonucunu almak çok uzun sürüyorsa bu durum, kodunuzu direkt olarak bir veritabanına veya bir dosya sistemine veya bir ağa bağımlı olmasından kaynaklanıyordur. Testlerin hızlı çalışması açısından kodların bu tür ortamlardan izole edilmesine dikkat edilmelidir. Test ortamında bu şekilde hız kazanmak mümkündür. Gerçek veritabanı ile dakikalarca sürecek testleri izole edilmiş ortamlarda saniyeler içinde gerçekleştirmek mümkündür.

TDD yaklaşımı genel olarak uygulamanın geliştirme sırasında ve ömrü boyunca devamlılığının sağlanabilmesi açısından size hız katar. Bir  çok firmanın sonraki versiyonlarını çıkaramadığı için çöpe giden uygulamaları vardır. Bir kurumda çalışan bir tanıdığımın anısıyla sözümü bitirmek istiyorum. Kurumuna yazılım yapan firmadan, mevcut yazılıma yeni bir özellik eklemesini istemiş. Firmanın verdiği cevap ise şu olmuş:  “Sen şimdi bir binanın aradaki bir katını kır ve araya bir kat ekle diyorsun, bu çok zor”.

Asp.net MVC JsonResult Tipli Metodlar İçin Unit Test

24 Nis

ASP.NET MVC mimarisi üzerinde test güdümlü çalışırken karşılaşacağımız test tiplerinden biri de JsonResult tipindeki action metodların testidir. Test tipinde veri döndüren metodların testleri kolay olabilmektedir. Ancak JsonResult tipindeki metodlar veriyi JSON tipine dönüştürerek sunduğu için, metod tarafından bize sunulan veriler text şeklinde olmayacaktır.

Normalde önce test metodu yazılarak gidilmelidir ancak burada test kodu geliştirmeyi konu almadığımız için, yazılmış metodu test ederek ilerlemeye çalışalım.

Test edilecek metod şu şekilde belirlenebilir.

public JsonResult GetMenu()
{
     var menu = new List<Menu>
     {
         new Menu{ MenuID=1, MenuName="Hamburger, Cola, Cips"},
         new Menu{ MenuID=2, MenuName="Cheeseburger, Cola, Cips"},
         new Menu{ MenuID=3, MenuName="Pizza, Cola, Cips"}
     };

     return Json(menu,JsonRequestBehavior.AllowGet);
}

Yemek menüsünü JSON formatında sunan bir metod.

Bu metodun test edilmesi sırasında aslında bazı sorulara yanıt arıyoruz olacağız. Bir başka deyişle önce test metodunun yazıldığı senaryolarda iddalar doğrulanarak gidilir. Bizim senaryomusda ise GetMenu metodunun:

  • Tipinin JsonResult olduğu iddası
  • Boş veri döndürmediği iddası
  • Dönen verinin formatının ne olacağının iddası

ortaya atılarak doğrulanmaya çalışılmıştır.


[TestMethod]
public void GetMenu_ShouldReturn_JSON()
{
    // Arrange
    HomeController controller = new HomeController();

    // Act
    var result = controller.GetMenu() as JsonResult;

    // Assert
    Assert.IsInstanceOfType(result, typeof(JsonResult));
    Assert.IsNotNull(result.Data);
}

İlk iki iddamızı bu metod sayesinde dğrulayabiliriz. Bu test başarıyla geçecektir. Ancak metodun döndürdüğü verinin ne olduğunu veya string şeklinde alınıp şuna eşittir denilebilmesi için serileştirilme işleminden geçirilmelidir. Çünkü result.Data nesnesi object tipindedir, ve içeriği okunamaz durumdadır. Serileştirilme işlemi sonrasında işlenebilir bir somut veri elde edilebilir.

     Assert.AreEqual("", result.Data.ToString());

Şeklinde bir idda hata döndürecektir. Test Fail duruma düşecektir.

Aşağıdaki lekilde serileştirme işlemini gerçekleştirdiğimizde bu tür sorunlarla karşılaşmayacağız.

[TestMethod]
public void GetMenu_ShouldReturn_JSON()
{
     // Arrange
     HomeController controller = new HomeController();

     // Act
     var result = controller.GetMenu() as JsonResult;

     var serializer = new JavaScriptSerializer();
     var output = serializer.Serialize(result.Data);

     // Assert
     Assert.IsInstanceOfType(result, typeof(JsonResult));
     Assert.IsNotNull(result.Data);
     Assert.AreEqual(@"[{""MenuID"":1,""MenuName"":""Hamburger, Cola, Cips""},
                        {""MenuID"":2,""MenuName"":""Cheeseburger, Cola, Cips""},
                        {""MenuID"":3,""MenuName"":""Pizza, Cola, Cips""}]",
                        output);
}

Tekrar görüşmek dileğiyle…