Karmaşık yazılımlar denildiğinde akla gelen ilk yöntem Domain Driven Design (DDD) olur. DDD yaklaşımını etki alanına dayalı yazılım olarak tercüme edilebilir. Etki alanı demek üzerinde çalışılan sektör ya da bölüm olarak düşünülebilir. Örneğin finans, e-ticaret, hastane, hava yolu, demir yolu vs gibi alanlar yazılımlar için etki alanları ya da Domain’ler olarak adlandırılabilir.
Etki Alanına Dayalı Tasarım (DDD), Eric Evans tarafından “Domain Driven Design: Tackling Complexity in the Heart of Software” adlı eserle ortaya atılan bir geliştirme felsefesidir. DDD, ekiplerin karmaşık sorun etki alanları için yazılımın geliştirilmesi ve bakımının etkin bir şekilde yönetmesini sağlayan bir yazılım geliştirme yaklaşımıdır. Bu yöntem bir programlama paradigması veya kodlama yöntemi değildir. Bu yöntem kodlamadan önce, çalışılacak iş ortamını(domain) tanımak, çalışma alanındaki gerçek dünyayı anlayarak düzgün bir şekilde tasnif etmektir diyebiliriz. Yazılımda yaşanan sorunların çoğu domain içinde saklıdır.
Karmaşık yazılımın zorlukları
Heyecanla ve pembe hayallerle başlanan karmaşık iş uygulamalarının modeli, zamanla en popüler yazılım mimari tasarım modeli olan Big Ball of Mud (BBoM) modeline dönüşür. Bu model Brian Foote ve Joseph Yoder tarafından yazılan bir makalede “gelişigüzel yapılandırılmış, özensiz, koli bandı ve balya teli yumağı, spagetti kodu ormanı” diye tarif edilmiştir. Bu modelde ayırt edilebilir mimariye sahip olmayan uygulamalar için kullanılır. (Bir tabak spagettiyi hayal edebilirsiniz.)
Şekil-1 de görüldüğü üzere yazılımdaki karmaşanın iki sebebi vardır.
- Yazılımın karmaşık ve yönetilmesinin zor olmasının ana nedenlerinden biri, alan karmaşıklıklarının teknik karmaşıklıklarla karıştırılmasıdır.
- İş akışındaki rutin değişiklikler ve küçük özellik geliştirmelerinin, mevcut kodu okuma ve anlamadaki zorluklar nedeniyle uygulanmasının zor olması.
Ortak Bir Dil Olmadan Oluşturulan Kod
İş uzmanlarıyla çalışan ekiplerin domain ortamında kullanılan kavramları, zengin kelime dağarcığı ile doğru bir şekilde yazılım ekiplerine aktarması gerekir. Aksi halde yeni domain kavramları ortaya çıkarılamaz veya geç ortaya çıkarılır maliyetler artar. Bu noktada, iş uzmanları ile geliştirme ekipleri arasında ortak bir dil oluşur. Ortak bir dile odaklanma eksikliği ve sorunlu domain bilgisi neticesinde, çalışan ancak işletmenin amacını ortaya çıkarmayan bir kod tabanı ortaya çıkar. Bu, kod tabanlarının okunmasını ve yönetilmesini zorlaştırır. Çünkü analiz modeli ile kod modeli arasındaki çeviriler maliyetli ve hataya açık olabilir. Sonuçta işletmenin analiz modelinden uzaklaşan kod yapısı ile uygulama bir BBoM modeline dönüşebilir.
İşletme analiz modeli nedir?
Yazılımın nasıl inşa edildiğini anlamak için teknik olmayan kişilerin kavramsallaştırabileceği yazılımın temsilidir. UML gibi modelleme dilleri kullanılarak temsil edilebilir. Bir yazılım uygulamasının mantıksal tasarımını ve yapısını tanımlamak için bir analiz modeli kullanılır.
Organizasyon Eksikliği
BBoM’ye dönüşen bir sistemin ilk üretimi çok hızlıdır. Belli bir domain etrafında kavramsallaştırılmamış uygulamalarda yeni geliştirmeler eklemek veya var olan özellikleri değiştirmek zahmetlidir. Kod tabanı, değişikliği yönetilebilir kılmak için iş davranışıyla gerekli uyumdan yoksundur. Problemin karmaşıklığı, teknik çözümün karmaşıklığı ile karıştırılır.
BBoM Deseninin Gelişimi Engellemesi
Spagetti benzeri bir desenle ısrar etmeye devam etmek, özellik geliştirme hızını yavaşlatır. Kod tabanının anlaşılmaz karmaşası nedeniyle, ürünün yeni sürümleri çıktığında hatalar oluşabilir. Zamanla, geliştirme ekibi böylesine bir karmaşa içinde çalışmanın zorluğundan giderek daha fazla şikayet eder. Projeye iş gücü kaynakları eklense bile hız, işi tatmin edecek seviyeye çıkarılamaz. Sonunda, durumdan bıkmış olarak, uygulamanın yeniden yazılması talebi kabul edilir. Başlangıçta hızlı geliştirilen ve teslim edilen uygulama, sonuçta olarak bir kabusa dönüşür.
Problem Alanına(Domain) Odaklanamama
Üzerinde çalıştığınız iş alanını anlamadan geliştirdiğiniz projeler başarısız olur. Yazılım projelerinin yapılması zor veya tıkandığı yer kodlama değildir. Kodlama, sürecin kolay bir bölümüdür. Zor olan, üzerinde çalışılan iş alanına faydalı, istekleri tam olarak yerine getirebilen bir yazılım modelini oluşturmak ve sürdürebilmektir.
İş alanınızı anlamaya ne kadar çok yatırım yaparsanız, iş sorunlarını çözmek ve onu yazılımda modellemek için o kadar donanımlı olursunuz.
Problem alanı(domain) nedir?
Problem alanı, üzerinde çalıştığınız ve yazılım geliştirdiğiniz alanı ifade eder. DDD bize karmaşık iş alanları için yazılım oluşturmaya çalışırken, her şeyden önce problem alanına odaklanmayı önerir. Faydalı bir yazılımın ortaya çıkabilmesi için alanında uzman kişiler yazılım ekipleriyle birlikte çalışır. Örneğin, sağlık sektöründe hasta kayıt yazılımı için doktor kadar bilgi sahibi olmaya gerek yoktur. Bilinmesi gereken, ilgili sağlık terimleri, kavramları, farklı departmanların hastalara ne tür işlemler yaptırdığı ve doktorların hastalardan neler talep ettiğidir.
Kaynaklar
- Patterns, Principles, and Practices of Domain-Driven Design
- Domain-Driven Design: Tackling Complexity in the Heart of Software
