DDD vs TDD vs BDD

Yazılım Geliştirme Yaklaşımları

Giriş

Geniş ölçekli yazılım geliştirme yaklaşımları için çok sayıda farklı modeller bulunmaktadır. Bu modellerden DDD, TDD ve BDD başlıkları aşağıdaki gibidir. Diğer modellere ve detaylarına Wiki’den erişebilirsiniz.

DDD vs TDD vs BDD

Domain Driven Desing(DDD)

Etki alanına dayalı tasarım, belirli bir etki alanı modelini çözmeye yönelik bir yazılım mühendisliği yaklaşımıdır. DDD, ilgili yazılım parçalarını sürekli gelişen bir modele bağlayarak karmaşık uygulamaların oluşturulmasını kolaylaştırmayı amaçlar.

Üç temel ilkeye odaklanır:

• Projenin birincil odak noktası çekirdek etki alanı(domain) ve etki alanı mantığıdır(domain logic).
• Karmaşık tasarımlar, alan modellerine dayalıdır.
• Teknik ve alan uzmanları arasındaki işbirliği, belirli alan sorunlarını çözecek bir uygulama modeli oluşturmak için çok önemlidir.

DDD Topoloji

Anahtar Bileşenler

• Domain, yazılım mühendisliğindeki alan genellikle uygulamanın uygulanması amaçlanan konu alanını ifade eder.
• Domain Logic, modellemenizin amacıdır. En yaygın olarak, iş mantığı olarak adlandırılır. Burası, iş kurallarınızın verilerin oluşturulma, saklanma ve değiştirilme şeklini tanımladığı yerdir.
• Domain Model, çözmeye çalıştığınız sorun etrafında dönen fikirleri, bilgileri, verileri, ölçümleri ve hedefleri içerir. Karmaşık iş mantığıyla başa çıkmanıza yardımcı olacak tüm kuralları ve kalıpları içerir. Ayrıca, işletmenizin gereksinimlerini karşılamak için faydalı olacaktır.
• Subdomain, iş mantığının farklı bölümlerine atıfta bulunan birkaç alt alandan oluşur. Örneğin, e-ticaret mağazasının alt alanları olarak bir ürün kataloğu, envanter ve teslimat olabilir.
• Design Patterns, yazılım tasarımında ortaya çıkan yaygın sorunlara karşı en basit ve en efektif biçimde yeniden kullanılabilir çözümler sağlar.
• Bounded Context, uygulamanın karmaşıklığını içeren etki alanına dayalı tasarımda merkezi bir kalıptır. Büyük modelleri ve ekipleri yönetir. Etki alanını ve alt etki alanlarını tanımladıktan sonra kodu uyguladığınız yer burasıdır.
• Ubiquitous Language, etki alanı modeli etrafında yapılandırılmış ve tüm ekip üyeleri tarafından ekibin tüm faaliyetlerini yazılıma bağlamak için kullanılan bir dil.

Yapı Taşları

Etki alanına dayalı tasarım, etki alanı modellerini oluşturmak ve değiştirmek için birbiriyle bağlantılı olarak kullanılabilecek üst düzey kavramları da tanımlar:

Entity, nitelikleriyle tanımlanan geleneksel nesnelerin aksine, tutarlı süreklilik zinciriyle tanımlanan bir nesne.

Value Object, Nitelikleri olan ancak belirgin bir kimliği olmayan değişmez (değiştirilemez) bir nesne. Örneğin, sevkiyat adresi bir değer nesnesi olabilir.

Domain Event, sistem içindeki model etkinliğiyle ilgili ayrı bir olayı kaydeden bir nesne. Sistem içerisindeki tüm eventler takip edilebilirken sadece domain uzmanlarının önemsediği event türleri için domain event oluşturulmaktadır.

Aggregate, Büyük ve karmaşık sistemler sayısız varlığa ve değer nesnesine sahiptir. Bu nedenle etki alanı modelinin bir tür yapıya ihtiyacı vardır. Bu, onları yönetmesi daha kolay olacak mantıksal gruplara yerleştirecektir. Bu gruplara Aggregate denir.

Domain Service, etki alanı mantığını da içeren ek bir katmandır. Tıpkı varlıklar ve değer nesneleri gibi etki alanı modelinin bir parçasıdır. Aynı zamanda uygulama servisi iş mantığı içermeyen bir diğer katmandır. Ancak, etki alanı modelinin üzerine yerleştirilen uygulamanın etkinliğini koordine etmek içindir.

Repositories, veri altyapısını basitleştiren bir iş varlıkları koleksiyonudur. belirli bir Aggregate içindeki tüm Entities ve Value Object’ lere erişim sağlamak için genel bir arabirim olarak kullanan bir hizmettir. Toplama içindeki nesnelerin oluşturulmasına, değiştirilmesine ve silinmesine izin vermek için yöntemler tanımlanmalıdır. Bununla birlikte, veri sorguları yapmak için bu havuz hizmetini kullanarak amaç, bu tür veri sorgulama yeteneklerini nesne modellerinin iş mantığından çıkarmaktır.

Factories, Bir nesnenin oluşturulması karmaşık hale geldiğinde veya iç yapı çok fazla ortaya çıktığında, Fabrikalar kapsülleme sağlar.

Avantajlar

• Simpler Communication. Daha basit iletişim.
• More Flexibility. DDD, nesne yönelimli analiz ve tasarıma dayalı yapısal bir sistemdir. Bu sayede tüm sistem düzenli olarak değiştirilebilir ve geliştirilebilir.
• The domain is more important than UI/UX.

Dezavantajlar

• Deep domain knowledge is needed. Geliştirme üzerinde çalışan teknolojik olarak en gelişmiş ekipler için bile, ekipte uygulamanın merkezi olan konu alanının kesin özelliklerini anlayan en az bir alan uzmanı bulunmalıdır. Bazen, geliştirme ekibine dahil edilecek etki alanını tamamen bilen birkaç ekip üyesine ihtiyaç vardır.
• Contains repetitive practices. DDD birçok tekrarlayan uygulama içerir. DDD, gerektiğinde kendilerini uyarlayabilen güçlü uygulamalar oluşturmak için sürekli entegrasyonun kullanılmasını teşvik eder.
• It might not work best for highly-technical projects. DDD, karmaşık iş mantığına sahip uygulamalar için mükemmeldir. Ancak, etki alanı karmaşıklığı az ancak teknik karmaşıklığı yüksek olan uygulamalar için en iyi çözüm olmayabilir. Büyük teknik karmaşıklığa sahip uygulamalar, iş odaklı alan uzmanları için çok zorlayıcı olabilir.

Test Driven Desing(TDD)

Test güdümlü geliştirme (TDD), yazılım gereksinimlerinin yazılım tam olarak geliştirilmeden önce test durumlarına dönüştürülmesine ve yazılımı tüm test durumlarına karşı tekrar tekrar test ederek tüm yazılım geliştirmenin izlenmesine dayanan bir yazılım geliştirme sürecidir.

TDD’de mutlaka test ilk sırada yazılmalıdır.

TDD Döngüsü

1. Bir test yazılır.
2. Test başarısız olur.
3. Test başarılı hale getirilir.
4. Mevcut bütün testlerin başarılı olması sağlanır.
5. Kod refactor edilir. Yani kodda iyileştirme ve/veya temizleme yapılır.

TDD Döngüsü

Avantajlar

• TDD, bir regresyon testi paketi oluşturur.
• TDD’nin metodik doğası, klasik aşamalı kod > test > düzeltme > yeniden test döngülerinden çok daha yüksek kapsam ve ilk seferde kalite sağlar.
• Testler tasarım döngüsünün en başından itibaren yapıldığından, sonraki aşamalarda hata giderme için harcanan zaman ve para en aza indirilir.

Dezavantajlar

• TDD, özellikle birim düzeyinde başarılı olmak için önemli bir beceri gerektirir.
• Ekipteki herkesin birim testleri oluşturması ve sürdürmesi gerekir, aksi takdirde hızla güncelliğini kaybederler.
• TDD’nin nihai sonuçları yalnızca kullanılan testler, bunların eksiksizliği ve nihai ürünün kullanıcılarının karşılaştığı koşulları ne ölçüde taklit ettikleri kadar iyidir.

Behavior Driven Desing(BDD)

Davranış odaklı geliştirme (BDD), bir yazılım projesinde geliştiriciler, kalite güvence uzmanları ve müşteri temsilcileri arasında işbirliğini teşvik eden çevik bir yazılım geliştirme sürecidir. Ekipleri, uygulamanın nasıl davranması gerektiğine dair ortak bir anlayışı resmileştirmek için konuşma ve somut örnekler kullanmaya teşvik eder.

Test güdümlü geliştirmeden (TDD) ortaya çıkmıştır. BDD, TDD’nin genel tekniklerini ve ilkelerini etki alanı güdümlü tasarım ve nesneden gelen fikirlerle birleştirir.

BDD Kümesi

BDD için Cucumber tool’u kullanılabilir. Cucumber’de Gherkin söz dizimi kullanılmaktadır. Gherkin, düz metni Cucumber’ın anlaması için yeterince yapılandırılmış hale getiren bir dizi gramer kuralıdır.

BDD ile Geliştirme Şablonu

Başlık: Talep içeriğine dair başlık

Anlatı, Hikaye: Talebe dair açıklamalar

• As a: Özellikten yararlanacak kişi ve/veya rol
• I want: Talep edilen özellik
• So that: Özelliğin yararı ve değeri

Kabul Kriterleri: Her bir özel senaryonun açıklaması

• Given: Senaryonun başlangıcındaki ilk bağlam
• When: Senaryoyu tetikleyen olay
• Then: Beklenen sonuç

Örnek BDD Senaryosu:

Başlık: Uçuş Arama ve Rezervasyon

Hikaye: Yolcuların web/mobil ekranlarında X şehrinden Y şehrine mevcut uçuşları arayabilmesi ve rezervasyon yapabilmesi

• As a: Yolcu
• I want: X şehrinden Y şehrine mevcut uçuşları arama ve rezervasyon yapılabilmesi
• So that: Çevrim içi rezervasyon yapılabilmesi, müşteri memnuniyeti, iş gücü kazancı

Kabul Kriterleri

• Given: Başlangıç ve hedef şehirlerin seçilmesi ve ilgili tarih aralıklarının girilmesi
• When: Arama butonuna basıldığında
• Then: Mevcut tüm uçuşları gösterir
• And: Seçilen uçuşa rezervasyon yapılır

BDD Döngüsü

Avantajlar

• Customer-driven product development. Müşteri odaklı geliştirme sağlar.
• Özelliklerin uygun şekilde önceliklendirilmesi
• Şeffaflık
• Daha az bakım ve risk
• Genel iş hedefleriyle daha iyi uyum

Dezavantajlar

• Müşteriyle çalışmak için bir geliştirici ekibi ayırma ihtiyacıdır.

Sonuç

Yazılım geliştirme yaklaşımlarından en uygun olanı seçmek/uygulamak iş süreçlerinize, iş gücünüze, odağınıza, geliştirilecek uygulama büyüklüğüne göre vb. parametrelerle değerlendirilebilir.

Kaynak

• https://en.wikipedia.org/wiki/List_of_software_development_philosophies
• https://en.wikipedia.org/wiki/Domain-driven_design
• https://en.wikipedia.org/wiki/Behavior-driven_development
• https://en.wikipedia.org/wiki/Test-driven_development
• https://www.spiceworks.com/tech/devops/articles/what-is-domain-driven-design/
• https://blog.airbrake.io/blog/software-design/domain-driven-design
• https://medium.com/microtica/the-concept-of-domain-driven-design-explained-3184c0fd7c3f
• https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
• https://martinfowler.com/bliki/BoundedContext.html
• https://cucumber.io/docs/bdd/
• https://www.scrum.org/resources/blog/behaviour-driven-development-bdd-helps-optimizing-value-work-done-scrum-team
• https://www.spiceworks.com/tech/devops/articles/what-is-bdd/
• https://testdriven.io/test-driven-development/
• https://cucumber.io/