Kompleks İş Süreçlerini Domain Driven Design Pattern Nasıl Yönetir?

Bu yazımda Domain Driven Design Pattern’ın kompleks iş süreçlerini nasıl yönettiğini ele almaya çalıştım. DDD iş süreçlerini temelde iki yapı altında yürütür. Bunlar: Stratejik ve Taktiksel kalıplardır. Bu çalışmada stratejik kalıpları tartışacağız. Bu bağlamda, DDD karmaşık iş süreçlerini 5 adımda yürüttüğünü söyleyebilirim. Bu adımlar aşağıda sırlanmaktadır.

· Problem Alanına Ayrıştırma

· Modeller Oluşturma

· Ortak Bir Dil Geliştirme

· Modellerin İzole Edilmesi

· Bağlamlar Arası İlişkileri Anlamak

Domain Driven Design (DDD), Eric Evans tarafından ufuk açan çalışmasında tanımlandığı gibi bir yazılım geliştirme felsefesidir (Tackling Complexity in the Heart of Software (Addison‐Wesley Professional, 2003). DDD, ekiplerin karmaşık sorun alanları için yazılımın geliştirilmesi ve onun bakımının etkin bir şekilde yönetmesini sağlayan bir yazılım geliştirme yaklaşımıdır. DDD’nin yazılım tasarımına nasıl yardımcı olabileceğini anlamak için, öncelikle yazılım geşitirmenin ve sürdürmenin zorluklarını anlamalısınız.

Karmaşık Problem Alanları İçin Yazılım Yaratma Zorlukları:

1. Ortak bir dil olmadan oluşturulan kod blokları

2. Organizasyon eksikliği

3. Yazılım geliştirme safhasını sekteye uğratan özel desenler

Yukarıda sunulan zorluklar göz önüne alındığında, DDD’ın hem bir problem alanını anlama hem de içindeki problemleri çözmek için faydalı olan sürdürülebilir bir çözüm oluşturma zorluğuyla ilgilendiği anlaşılmaktadır. DDD bunu, bir dizi stratejik ve taktiksel kalıp kullanarak gerçekleştirir. Kullanılan bu kalıp aracılığıyla karmaşık iş süreçleri kolaylıkla yönetilebilir hale gelmektedir.

1. DDD’nin Stratejik Kalıpları

DDD’nin stratejik kalıpları, problem alanını ayrıştırmak ve bir uygulamanın mimarisini şekillendirmektedir.

Problem Alanı (Problem Domain) Nedir?

Sorun yada problem alanı, yazılım oluşturulurken ki konu alanlarını vurgulamaktır. DDD, büyük ölçekli ve karmaşık domain sistemleri için yazılım oluşturulurken, her şeyin üstünde domain’e odaklanma ihtiyacını vurgulamaktadır. Sorun alanındaki uzmanlar geliştirme ekibiyle birlikte çalışarak etki alanıyla ilgili kaliteli yazılım üretebilmek için faydalı olan alanlara odaklanırlar. Örneğin sağlık endüstrisi için hasta tedavi yöntem ve aşamalarını kaydetmek için bir yazılım geliştiriliyor, böyle bir durumda doktorların sahip olduğu bilgiyi öğrenmek önemli değildir. Projeyi anlamak için önemli olan sağlık sektörünün terminolojisi, farklı bölümlerin hastaları ve bakımı nasıl gördükleri, doktorların hangi bilgileri topladıkları ve bunula ne yaptıklarıdır.

1.1. Neyin Önemli Olduğunu Göstermek için Problem Alanını Ayrıştırma

Büyük bir yazılım ürününün tümünün mükemmel bir şekilde tasarlanması gerekmez. Zaten büyük bir yazılımı tamamıyla mükemmel bir şekilde geliştirme fikri zaten gerçeği yansıtmamaktadır. Projelere genellikle veri tabanı deseni çıkartılarak başlanılır ve projeyi geliştirme esnasında karşılaşılan çözümlere pratik çözümler bulunmaya çalışılır. Böylelikle kod blokları git gide spagetti koda dönüşür.

Geliştirme ekipleri ve domain uzmanları büyük sorun alanlarını daha yönetilebilir alanlara ayrıştırmak için analiz kalıplarını kullanılırlar.

Analiz Modeli (Analysis Model) Nedir?

Analiz modeli bir yazılım uygulamasının mantıksal tasarımını ve yapısını tanımlamak için kullanılmaktadır. Analiz modelleri taslak çizimler yada UML gibi modelleme dilleri kullanılarak gösterilebilir. Ayrıca analiz modeli yazılımın nasıl inşa edildiğini anlamak için teknik olmayan kişilerin kavramsallaştırdığı yazılımın temsilidir.

Bu ayrıştırma, yazılımın geliştirilmesinin sebebi olan çekirdek alt etki alanlarını açığa çıkartır. Alt etki alanı, geliştirilmekte olan ürünün arkasındaki itici güçtür. Bu güç ise ayrıştırmanın neden yapılması gerektiğinin temel nedeni olarak gösterilmektedir. DDD, alt etki alanları üzerine odaklanmayı vurgulamaktadır. Alt etki alanları uygulamaların başarıları için en önemli anahtarlardır.

Alt etki alanlarını keşfetmek, ekiplerin niçin yazılımı ürettiklerini ve yazılımın şirket için başarılı olmasının ne demek olduğunu anlamalarına yardımcı olur. Ayrıca geliştirme ekibinin, sistemin en önemli bölümlerini belirlemesine ve bu bölümlere gerekli zamanı ayırmalarını temin eder. Yazılım geliştikçe yazılımın uyarlanabilir olması gerekmektedir. Uygulamanın kilit alanları için kod kalitesine yatırım yapmak, yazılımın iş alanıyla(business domain) birlikte gelişmesine yardımcı olur. Bu durum göz ardı edilirse yani yazılımın kilit alanları ile iş alanlarının parçalarının bir bütün oluşturamamasın neden olur. Böylelikle tasarım işlevsiz hale gelir.

1.2. Etki Alanı(Domain Problems) Sorunlarını Çözmek İçin Bir Model Oluşturma

Çözüm alanı içerisinde her bir alt etki alanı için etki alanı sorunlarını ele almak ve yazılımın domain hatlarını sıralamak için bir yazılım modeli oluşturulur. Bu model gerçek hayatı yansıtan bir model değildir fakat bir yandan business domain kurallarını ve mantığını korurken, diğer yandan iş kullanımı durumlarının gerekliliklerini yerine getirmek için yapılmış bir soyutlamadır. Geliştirme ekibi, model ve domain logic üzerine odaklandığı ve gösterdiği kadar uygulamanın salt teknik yönlerine de üzerinde çok enerji harcamalıdır. Kazara oluşabilecek teknik karmaşıklıktan uzak durabilmek için model altyapı kodlarından izole edilmelidir.

Tüm modeller eşit yaratılmamıştır; tüm sisteme kapsayacak tek bir tasarım deseni uygulamak yerine, her bir alt alanın karmaşıklık seviyesine cevap verebilecek gereksinimlerine sahip en uygun tasarım desenleri kullanılmaktadır. Ürünün başarısı için temel teşkil etmeyen veya karmaşık olmayan alt etki alanları için modeller nesne yönelimli tasarımlara dayanmak zorundadır.

1.3. Modelleme Safhasının İşbirliğini Etkinleştirmek için Paylaşılan Dil Kullanma

Modeller, etki alanı uzmanlarının ve geliştirme ekibinin işbirliği ile oluşturulmaktadır. İletişim, bir yazılım modelini kavramsal analiz modeline, verimli ve etkili bir şekilde bağlamak için her zaman kullanılan dil (UL-Ubiquitous Language) olarak bilinen sürekli gelişen ve paylaşılan bir yapı kullanılarak gerçekleştirilir. Yazılım modeli, yapısı ve sınıf tasarımı için aynı UL terimlerini kullanarak analiz modeline bağlanmaktadır. Kodlama seviyesinde keşfedilen kavramlar ve terimler UL’de ve dolayısıyla analitik modelde çoğaltılır. Aynı şekilde, işletme analiz modeli düzeyinde gizli konseptleri ortaya çıkardığında, bu öngörü kod modeline geri beslenir; etki alanı uzmanlarının ve geliştirme ekiplerinin modeli işbirliği içinde geliştirmelerini sağlayan anahtar budur.

1.4. Modellerin İzole Edilmesi

Modeller, modelin uygulanabilirliğini tanımlayan ve bütünlüğünün korunmasını sağlayan sınırlı bir bağlamda oturmaktadır. Daha büyük modeller daha küçük modellere ayrılabilir ve terminolojideki belirsizliğin olduğu veya karmaşıklığı daha da azaltmak için birden fazla takımın çalıştığı ayrı sınırlı bağlamlarda tanımlanabilir.

Sınırlı bağlamlar, yazılımların çalışmaz ve hatalara boğulmuş kod yığınlarına dönüşmesini engellemeye yardımcı olan modeller etrafında koruyucu bir sınır oluşturmak için kullanılır. Bu, genel çözümün farklı modellerinin, sistemin diğer bölümleri üzerinde olumsuz, dalgalanan bir etkiye sahip olmadan, iyi tanımlanmış iş ortamlarında gelişmesine izin verilerek elde edilir. Modeller, teknik ve işletme kavramlarının birleştirilmesinin yanlışlıkla karmaşıklığını önlemek için altyapı kodundan izole edilmiştir. Sınırlı bağlamlar aynı zamanda 3rd-party kodlardan izole edilerek modellerin bütünlüğünün bozulmasını önler.

1.5. Bağlamlar Arasındaki İlişkileri Anlamak

DDD, alt alanlara yayılan etki alanı sorunlarını çözmek için ekiplerin ve iş dünyasının ayrı modellerin ve bağlamların birlikte nasıl çalıştığı konusunda açık ve net olmalarını sağlamaktadır. Bağlam haritaları, büyük resmi anlamanıza yardımcı olur; Ekiplerin hangi modellerin mevcut olduğunu, neyin sorumlu olduğunu ve uygulanabilirlik sınırlarının nerede olduğunu anlamalarını sağlar. Bu haritalar, farklı modellerin nasıl etkileşime girdiğini ve iş süreçlerini yerine getirmek için hangi verileri değiştirdiklerini ortaya koyuyor. Bağlantılar arasındaki ilişki ve daha da önemlisi, aralarında duran süreç alanı genellikle iş tarafından ele geçirilmez veya iyi anlaşılmaz.