Domain Driven Design Nedir ve Ürün Geliştirmeyi Nasıl Destekleyebilir?

Domain-Driven Design Nedir (DDD) yazılım ve dijital ürün tasarımında köklü bir kavramdır. Bu makalede, önerilen DDD mimarisinin bir taslağı ve dijital ürününüz için alan odaklı bir yaklaşım kullanmanın temel artıları ve eksileri dahil olmak üzere DDD ve temel kavramları hakkında basit bir açıklama sunuyoruz.

Bir açıdan bakıldığında dijital ürününüz (uygulamanız) kodlardan oluşuyor. Ancak, başka bir açıdan baktığımızda bundan çok daha fazlası olduğunu söyleyebiliriz. Uygulamanızdaki, platformunuzdaki veya web sitenizdeki kod – önemli olsa da – daha büyük, daha karmaşık bir sistemin veya “alan”ın (domain) yalnızca bir parçasıdır. Ürününüzün domain’i temel olarak ürününüzün hitap ettiği ve/veya içinde çalıştığı konu alanıdır. Ürünün yerine getirmeyi amaçladığı kullanıcı gereksinimlerini, katkıda bulunacağı iş hedeflerini ve onu tanımlamak ve tartışmak için kullanılan terminolojiyi içerir. Domain daha sonra programlama dilleri, kullanılacak cihazlar ve diğer donanımlar ve elbette programlanmış kod, ürünün kendisinin işlevleri ve özellikleri gibi daha teknik konuları etkiler. Ürün ve domain’i ne kadar karmaşıksa, o alanın tüm unsurlarını tasarım ve geliştirme sürecine dahil etmek o kadar önemlidir.

Domain-Driven Design Nedir Kısa Bir Tanımı

Tasarım süreciniz etki alanına dayalı (domain-driven) olduğunda, domain’in bir modelini sürecin kendisine dahil eder. Ürünün tasarımında ve geliştirilmesinde yer alan herkes tarafından ortak bir dil ve terminoloji kullanan ve ürünün neden üretildiğine dair ortak bir anlayış kullanan ortak bir yaklaşım kullanılır.

Domain Driven Design kavramı ilk olarak Eric Evans tarafından 2004 yılında yayınlanan “Domain-Driven Design: Tackling Complexity in the Heart of Software” adlı kitabında detaylandırılmıştır. Evans’ın kitabının merkezinde, yalnızca ürünün tasarımına dahil olan herkesin ortak bir dile ihtiyaç duymadığı, aynı zamanda bu dilin de oluşturulacak ürünün temel bir parçası olması gerektiği kavramı yer alıyor.

Başka bir deyişle, domain driven design, oluşturulan ürünün nihai yararına teknik ve teknik olmayan katkı sağlayanların (konu uzmanları gibi) birbirleriyle iletişim kurmasını ve anlamasını sağlayan bir işbirliği sistemidir.

Domain-Driven Design Nedir : Anahtar Terminoloji

DDD’nin bileşenlerine açıklık getirmenin bir yolu, aşağıdaki gibi temel terminolojiye odaklanmaktır:

• Domain model – Domain model dijital ürününüzün çözmeyi amaçladığı sorunla ilgili her şeyi, tüm iş kavramlarını, verileri ve bilgileri içerir.
• Subdomain –  Domain model, her biri domain’in farklı bir öğesiyle veya dijital ürünün ele aldığı sorunla ilgili alt etki domain’lere bölünmüştür.
• Bounded context (Sınırlı bağlam) – Domain model (ve subdomain’ler), sorunun ayrıntılı ve pratik bir ifadesidir. DDD fikri, çözümün (dijital ürününüzün kodlama yapısı dahil) sorunu yansıtmasıdır. Ancak, domain ne kadar karmaşıksa, subdomain’leri kullanmanız o kadar olasıdır.
• Domain logic – ‘Business Logic’ olarak da adlandırılır. Ürün tarafından kullanılan verilerin oluşturulmasını, depolanmasını ve değiştirilmesini belirleyen bir dizi kural veya normdur.
• Design pattern (Tasarım deseni) – Tasarım desenleri, ürününüzün ele almayı amaçladığı sorunun farklı unsurlarını ele alan önceden yazılmış kod parçalarıdır. Sorunu ayrı bileşen zorluklarına ayırın ve muhtemelen geçmiş tasarım modellerinin birçoğunu çözmek için kullanılabileceğini göreceksiniz.
• Ubiquitous Language – Her uzman grubunun kendi jargonu, uzmanlıkla ilgili dilleri vardır. Dijital ürün geliştirmede çeşitli uzmanlar bir araya gelir; yalnızca front-end ve back-end geliştiricileri değil, aynı zamanda kalite güvence uzmanları, iş analistleri, konu uzmanları vb. Domain Driven Design, ilgili tüm uzmanlar tarafından daha sonra tasarım ve geliştirme sürecinin tüm yönlerinde (her yerde bulunan dil terminolojisini kullanacak olan kod dahil) kullanılan terminoloji ve tanımları kabul etmeyi içerir. Doğal olarak, üzerinde anlaşılan tüm terminoloji, bir şekilde genel etki alanı modeline bağlıdır.

Neden Domain-Driven Design Yaklaşımını Kullanıyoruz?

Domain-driven design tutarlı bir tasarım süreci için ideal bir yoldur. Bununla birlikte, potansiyel olarak son derece verimli olsa da, daha basit dijital ürünler için çok fazla (gereksiz) olabilir. DDD, karmaşık sorunlara veya karmaşık ve çeşitli bir iş ortamı içinde çalışması ve bu ortamı dikkate alması beklenen ürünlere en uygun olanıdır; yani çok sayıda veri kaynağı, veriler arasında çeşitli ara bağlantılar ve çoklu çıktılar gibi. Benzer şekilde, DDD’nin hedeflerinden biri de tasarım sürecinin teknik ve ticari yönlerini bir araya getirmektir. Muhtemelen, dijital ürününüzün desteklediği iş hedefi ne kadar önemliyse, etki alanına dayalı bir yaklaşım kullanma durumu o kadar güçlü olur.

Son olarak, geniş ve çeşitli bir tasarım ekibi ve paydaş grubuyla, etki alanına dayalı olmaktan kaynaklanan ortak dil, yanlış anlamaların dijital ürününüz için ölümcül olabileceği bir ortamda net iletişim ve tartışma sağlanmasına yardımcı olur.

Karmaşıklıkları Kodlamak

Şimdiye kadar, DDD’nin tasarım sürecini nasıl düzenlediğinden ve etkilediğinden, farklı geçmişlere ve yeterliliklere sahip kişiler arasında daha verimli çalışmayı kolaylaştırdığından bahsettik. Ancak alan odaklı tasarım yaklaşımı, dijital ürününüzün koduna, mimarisine de uygulanabilir.

Sorun şu ki, karmaşık bir etki alanında veya karmaşık bir üründe, farklı öğeler etkileşime girer ve bu nedenle birbiriyle ilişkilidir – örneğin, devam eden bakım ve güncellemenizin bir parçası olarak bir iş kuralında değişiklik yaparsanız, kullanıcı arabiriminizin veya veritabanınızın nasıl çalıştığıyla ilgili sonuçlar bulabilirsiniz. Cevap her zaman basitliği yaratmak ve sürdürmektir. Karmaşık bir domain’i daha küçük problemlere bölmenin bir yolu olarak subdomain’lerin kullanımında olduğu gibi, kodlama yapınız açısından DDD çözümü, karmaşıklıkları yönetmek için katmanlı bir mimari kullanmaktır. Her katman birbirine bağlıdır ve aşağıdaki katmanlara bağlıdır (yani veri gerektirir veya bunlardan etkilenir). Başka bir deyişle, daha yüksek katmanlar daha düşük katmanlara atıfta bulunur, ancak tam tersi değil. Eric Evans’ın kitabı dört katman önerir:

• User Interface (Kullanıcı arayüzü) (veya Presentation) Katmanı – kullanıcılara bilgi ve veri görüntüler, kullanıcı girdilerini ve komutlarını kabul eder ve yorumlar.
• Application (Uygulama) katmanı – kendisi iş kurallarını içermese de dijital ürünün etkinliğini iş kurallarına göre koordine eder.
• Infrastructure (Altyapı) katmanı – diğer katmanlar ile harici hizmetler ve kaynaklar (örn. dosya sistemi, önbellek, loglama, queue, e-posta, search index vb.) arasındaki iletişimi destekler, ayrıca depolamayı ve verilere erişimi yönetir.
• Domain katmanı – etki alanı, tüm iş kuralları ve mantığı ve business state (belirli bir anda sistemin mevcut yapılandırması) hakkında bilgi içerir.

Dijital ürününüz dört katmanın tümüne ihtiyaç duymayabilir, ancak alan odaklı bir tasarım yaklaşımı benimsiyorsanız, domain katmanı çok önemlidir.

Domain-Driven Design’in Faydaları

Karmaşık uygulamalar için, etki alanına dayalı bir yaklaşımı benimsemek, tasarım süreciniz için aşağıdaki faydaları sunar:

• Gelişmiş iletişim – ubiquitous language öğesi, özellikle geliştirme ekibinin teknik ve teknik olmayan üyeleri arasında daha kolay ve daha basit iletişim sağlar.

• İş hedeflerinizle uyumlu – dijital ürünün amaçlanan iş sonuçlarına ilişkin netlik ve tutarlılıkla, işinizin nasıl yürüdüğünü yansıtan bir ürün yaratmanız daha olasıdır.

• Esneklik – katmanlı ve modüler bir tasarımla, ihtiyaç duyulduğunda daha az istenmeyen etkiyle ürününüzü güncellemek, değiştirmek ve modernize etmek daha kolaydır. Verimlilik – basitçe, konu uzmanlarının yakın (ve anlaşılır) katılımıyla, bir geliştiricinin yapması gerektiğini veya yapabileceğini düşündüğü işin aksine, ürünün yapması gereken işi yapması daha olasıdır; yani, kimsenin kullanmayacağı özelliklere sahip olma olasılığı daha düşüktür. DDD’nin kapsamlı alan uzmanlığı ve girdisi gerektirdiğini kabul etmek gerekir. Bu kulağa bariz gelebilir, ancak daha uzun (ve dolayısıyla daha pahalı) bir tasarım süreci ile sonuçlanabilir. Karmaşık ürünler veya karmaşık bir alanda faaliyet gösteren ürünler için, DDD kesinlikle en etkili ve verimli yaklaşımdır (özellikle scrum gibi Çevik bir metodoloji ile birleştirildiğinde).

Özet

Domain-driven tasarım, çeşitli uzmanlık kaynaklarından ayrıntılı ve çeşitli girdiler gerektiren karmaşık ürünler için dijital ürün geliştirmeye yönelik bütünsel bir yaklaşımdır ve ortak bir dil ve terminoloji anlaşması ve kullanımı yoluyla daha etkili işbirliği sağlar. Nihai ürünün iş öncelikleriniz ve hedeflerinizle tam olarak uyumlu olmasını sağlamak için iyi çalışan ve bundan en çok yararlanacak kullanıcıları hedefleyen DDD, aynı şekilde, katmanlı bir mimarinin benimsenmesi, bakımı ve yükseltilmesi daha kolay olan bir teknik tasarımla sonuçlanır, böylece potansiyel olarak ürünün yaşam döngüsünü uzatır. DDD, her dijital ürün için doğru bir geliştirme yaklaşımı seçimi değildir, ancak olduğu zaman, sonuçlar her zaman daha iyidir.