Yazının orjinaline buradan ulaşabilirsiniz.
Tüm yazılım sistemleri umarım gerçek bir dünya problemini çözmek için tasarlanmıştır. Bunu yapabilmek için, yazılımın birlikte çalışabileceği problemin bir soyutlamasına - bir modele - ihtiyacı vardır. Bu modeli bulmak her zaman kolay değildir, özellikle de gerçek dünya sorunu karmaşıksa.
Etki Alanına Dayalı Tasarım (DDD), modeli bulmamıza yardımcı olabilecek bir yazılım tasarım sürecidir. Modelimizi keşfetmek ve tasarlamak ve onu çalışma koduna dönüştürmek için gerekli araçları ve yapı taşlarını verir.
DDD sürecinin en önemli çıktıları, problem alanının ortak anlayışı ve onu tanımlayacak bir dildir. Çözmekte olduğunuz problemin kavramlarını ve süreçlerini tanımlayamıyorsanız, herkes - hem müşteriler hem de geliştiriciler - onları anlayın, o zaman modelinizde bir şey eksik ve bunun ne olduğunu bulmanız gerekiyor. Bu anlayışı ve bu dili tam olarak nasıl belgelediğiniz, projeniz için çalıştığı sürece daha az önemlidir. Benim kişisel favorim UML diyagramları ve bir wiki kullanmak, ancak başka alternatifler de var.
DDD web seminerinde, alan modelleme sürecinin pratikte nasıl görünebileceğini gösteriyoruz. Bir tasarımcı ve bir etki alanı uzmanının (müşteri), etki alanı modelini bir iPad'de UML'de belgelerken belirli bir iş sorununu tartıştığı bir senaryoyu yeniden canlandırıyoruz. Buradaki anahtar, teknik malzemeyi, çoğu durumda yazılım geliştirme hakkında fazla bir şey bilmeyen müşteri de dahil olmak üzere, dahil olan herkesin modeli anlayabileceği bir seviyede tutmaktır.
Ayrıca sürece biraz UX tasarımı da ekledik, çünkü bunun bizi sorun alanına farklı bir açıdan bakmaya ve aksi takdirde gözden kaçıracağımız şeyleri keşfetmeye zorladığını (web seminerinde de göstermeye çalıştığımız) keşfettik. Sonuç, etki alanı modelinin, UX tasarımının ve etki alanı uzmanıyla yapılan tartışmanın birbirini etkilediği bir geri bildirim döngüsüdür ve biz onu kodda gerçekten çözecek kadar bilgi sahibi olana kadar yavaş yavaş sorunu anlamamızı sağlar.
DDD ayrıca yazılımı tasarlamak ve uygulamak için kalıplar içerir. Varlıklar, değer nesneleri, kümeler, depolar ve hizmetler gibi kavramları duymuş olabilirsiniz. Bunları bu web seminerinde ele almıyoruz, ancak örnek kodu yazarken bunları kullanmaya çalıştım.
Son olarak, DDD'den kazanç elde edebilmek için her şeyi yapmanıza gerek yoktur. Tam DDD, ustalaşmak için pratik gerektirir ve ben hala kendimi bu konuda yeni başlayan biri olarak görüyorum. Buna rağmen birçok projede DDD ilkeleri bize yardımcı oldu. Örneğin, ciddi veri tutarlılığı sorunları yaşadığımız kötüleşen bir proje vardı. Veriler kopyalandı veya hiç kaydedilmedi ve görünüşte rastgele bir şekilde iyimser kilitleme hataları oluştu. Varlıkları, değer nesnelerini, kümeleri ve depoları kullanmak için kodumuzu yeniden yapılandırarak projeyi tekrar rayına oturtmayı başardık. Bununla, DDD'ye aşina olmanızı ve projeniz için yararlı olabileceğini düşündüğünüz parçaları seçmenizi teşvik etmek istiyorum.
DDD hakkında daha fazla bilgi edinmek istiyorsanız şu kaynaklara bir göz atın:
Her şeyi başlatan kitap: Eric Evans'ın Domain Driven Design. Projelerinizde gerçekten DDD kullanmaya başlamak istiyorsanız bu kitap kitaplığınızda olmalı.
DDD kitabının tamamını okumak için zamanınız yoksa veya şu anda bir şeye ihtiyacınız varsa, DDD'nin temellerinin bu kaynaktan okuyabilirsiniz:
Okumayı izlemeyi ve dinlemeyi tercih ediyorsanız, YouTube'daki bu konuşmalara göz atabilirsiniz (elbette web seminerimize ek olarak):