ÇSTech
Published in

ÇSTech

Domain Driven Design 101

Photo by Tim Mossholder on Unsplash

Yazılımın kalbi, kullanıcısı için domain ile ilgili problemlemleri çözebilme yeteneğidir.

Eric Evans

Domain-Driven Design Tackling Complexity in the Heart of Software — Eric Evans

Domain-Driven Design (DDD) kompleks domain problemlerine sahip yazılımları geliştirmek için bir dil ve domain merkezli bir yaklaşımdır. DDD terimi Eric Evans tarafından “Domain-Driven Design: Tackling Complexity in the Heart of Software” kitabında ortaya konmuştur.

DDD hem teknik hem de iş alanlarında karmaşıklığı sahip yazılımları üreten ekiplerin başarıya odaklanması için bazı pattern ve prensiplerden oluşur.

Yazılımın sahip olduğu kompleksite, domain’den katılsal olarak gelen kompleksite ile teknik kompleksitenin birleşmesi sonucu ortaya çıkar.

Kompleks Problemleri Domain Modelleri Kullanarak Çözün

Bir domain modeli gerçekliği değil, bir perspektifi ifade eder. Bu perspektif ise çözülmek istenen problemdir. Bu modelin çeşitli ifadeleri olan kod, diyagram, döküman ise aynı dil ile bağlıdır.

Model, yalnızca yaratılan uygulama bağlamındaki sorunları çözmek için ilgili olan detayları içerir. Yeni use case’ler domain’e dahil oldukça, model’in geçerli kalabilmesi için sürekli olarak gelişmeye ihtiyacı vardır.

  • İlk iyi fikrinizde durmayın.
  • Her yeni problem ile birlikte modelinizi sorgulayın.
  • Gerçek hayatı modellemeye çalışmayın.

Yazılım projelerinin en karmaşık kısmı domain’in kendisini anlamaktır.

Eric Evans

Ubiquitous Language Kullanarak Model Dizayn Etmek

Yazılım çözümleri genellikle kötü iletişim ve domain ile teknik dil arasındaki terminoloji farklılıklarından dolayı başarısız sonuçlanır.

Ubiquitous Language, teknik ve domain çeviri maliyetini en aza indirir ve tüm ifadeleri “true model” olarak da bilinen kod modeline bağlar. Paylaşılan bir dil, modelleme sırasında keşiflere de yardımcı olur ve domain’e derinlemesine bir hakimiyet oluşturabilir.

Ubiquitous Language modelin kod implementasyonu yapılırken class isimlerinde, property’lerde ve metod isimlendirmelerinde aynı şekilde kullanılmalıdır. DDD’nin sürekli gelişmesi modeli bu ortak dili kullanmaktan geçmektedir.

Ubiquitous Language Kullanarak Model Dizayn Etmek

Yazılım çözümleri genellikle kötü iletişim ve domain ile teknik dil arasındaki terminoloji farklılıklarından dolayı başarısız sonuçlanır.

Herhangi bir programcı, bilgisayarın anlayabileceği şekilde kod yazabilir. İyi programcılar ise insanların anlayabileceği kodlar yazar.

Martin Flower

İşbirlikçi ve Sürekli Gelişen Modelleme

İşbirlikçi modellemenin en büyük yararlarından biri iş birimi tarafından sürekli olarak geri bildirim alıyor olmaktır. Sürekli geri bildirim alıyor olmak, development takımının modelde neyin önemli olup olmadığını fark etmesi için oldukça önemlidir.

Karışık ve Büyük Modelleri Bounded Context’lere Ayırın

Zamanla modeliniz bütünlüğünü ve kendini açıkça ifade edebilme özelliğini kaybedebilir, kompleksitesi artar ve üzerinde çalışan takımların kullandığı dil ifadesizleşebilir. Bu durumda, büyük ve kompleks modeller, bir modelin belli bir bağlamda anlaşılabileceği sınırlarda bounded context’lere ayrılmalıdır.

Bunu yapamadığınız takdirde ise, yazılımınızın “big ball of mud” modeline dönmemesi ihtimali çok düşüktür.

Context’lerde Önemli Noktalara Dikkat Edin

DDD’nin Göze Çarpan Noktaları

Kompleks domain’lere sahip yazılımları efektif ve bakım yapılabilir şekilde ortaya koyabilmek için iteratif döngülerle çalışan kendini adamış takımlara ihtiyaç vardır. Eric Evans’ın gözlemlemiş olduğu üzere teknik yetkinlikler size sadece bir yere kadar götürebilir. Problem domain’ine odaklanılmayan, domain expert’leri ile çalışmayan yada ubiquitous language kullanımına dikkat edilmeyen bir ortam sizi “big ball of mud” modeline sürükleyebilir.

Önemli Noktalara Efor Harcayın

Her tasarladığınız sistem iyi tasarlanmak zorunda değildir ki sürekli bunu istemek bütçeniz için iyi olmaz. Bunun yerine core domain’inizi tanımlayıp eforunuzu buraya harcamak daha mantıklı olacaktır. Zaten ortaya çıkaracağınız yazılıma yol açan şey core domain’dir.
DDD uygulaması zor ve zaman alıcı bir yöntemdir bu yüzden bazen sadece kodlamaya başlamak, problem olmayan bir yerde problem aramaya çalışmaktan iyidir.

Bounded Context İçinde Modelleme

Büyük bir domain için modelleri oluştururken, eğer birden fazla ekip varsa, kullanılan dil açıklığını kaybedebilir. Bu yüzden domain ilk olarak context’lere ayrılıp, modelleri bunun üstünden geliştirmelisiniz. Bu noktada context herşeydir; context ve izolasyon kodunuzun bütünlüğünü sağlar ve birden fazla ekibin aynı anda çalışabilmesini sağlar.

Modelin Kendisini Ubiquitous Language ile İfade Etmesi

Yazılım projeleri kötü iletişim ile birlikte, domain ile teknik terminoloji arasındaki dönüşüm maliyeti yüzünden başarısız sonuçlanabilir.
Ubiquitous Language, development ekibinin kod modelini, domain expert’leri ile yapılan konuşmalar ve diyagramlar gibi ifade şekillerine bağlamasını sağlayarak daha etkili bir iletişim sağlar. Bu nedenle, kod modelinin Ubiquitous Language kullanılarak açıkça ifade edilmesi hayati önem taşımaktadır ve Ubiquitous Language’e takıntılı olmak oldukça önemlidir.

Modelleme ve Gelişimde İşbirliği

Yazılımcılar ile domain expert’lerinin sürekli olarak iş birliği içinde olması ile ortaya çıkan öğrenmenin göz ardı edilmemelidir. Bilginin yoğun şekilde paylaşılması sürekli olarak devam edecek bir süreçtir, bir projenin başlaması gibi olaylar ile sınırlı kalmamalıdır. Derin bilgi hakimiyeti, problemli domain üstünde ancak sürekli olarak geliştirme döngüsü sonucunda elde dilebilir. “Çalışan yazılım genellikle öğrenmenin çıktısıdır” şeklinde de söylenebilir.

Yazının sunum haline https://metinirden.github.io/ddd-101/ adresinden ulaşabilirsiniz :)

--

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Metin İRDEN

Metin İRDEN

Software Engineer @Çiçeksepeti

More from Medium

Software Systems at Mizu

Monolith to Microservices: Background Transformation

Image Reference: “https://www.quora.com/How-can-Scrum-Kanban-be-used-with-microservices-architecture”

Moving from monolith to microservices? Take a leaf out of the Strangler Fig Approach

Moving from monolith to microservices? Take a leaf out of the Strangler Fig Approach

GraphQL — Benefits for Teams