Yeni bir proje üzerinde çalışmaya başladım ve etki alanı güdümlü tasarım kullanıyoruz (Eric Evans tarafından Domain-Driven Design: Yazılımın Kalbinde Karmaşıklıkla Mücadele'de tanımlandığı gibi) . Evans'ın kitabında tarif ettiği gibi.
Sürekli olarak yeniden düzenleme fikri ile mücadele ediyorum.
Yeniden düzenlemenin herhangi bir projede bir zorunluluk olduğunu biliyorum ve yazılım değiştikçe kaçınılmaz olarak gerçekleşecek. Ancak, benim tecrübelerime göre, yeniden düzenleme, geliştirme ekibinin ihtiyaçları değiştiğinde, etki alanı değişikliklerinin anlaşılması olarak değil (Evans'ın dediği gibi "daha büyük kavrayışa yeniden düzenleme") gerçekleşir. En çok etki alanı modelini anlamadaki atılımlarla ilgileniyorum . Küçük değişiklikler yapmayı anlıyorum, ama modelde büyük bir değişiklik gerekiyorsa ne olur?
Daha net bir etki alanı modeli elde ettikten sonra kendinizi (ve diğerlerini) yeniden düzenlemeniz gerektiğine ikna etmenin etkili bir yolu nedir? Sonuçta, kod organizasyonunu veya performansını iyileştirmek için yeniden düzenleme, her yerde bulunan dil kodu açısından ne kadar etkileyici olduğundan tamamen farklı olabilir. Bazen sadece refactor için yeterli zaman yok gibi görünüyor.
Neyse ki, SCRUM kendini yeniden düzenlemeye borçludur. SCRUM'un yinelemeli doğası, küçük bir parça ve değişiklik yapmayı kolaylaştırır. Ama zamanla bu parça büyüyecek ve eğer o parçadan sonra bir atılımınız varsa o kadar büyük olacak ki değiştirmek çok zor olacak?
Etki alanı odaklı tasarım kullanan bir proje üzerinde çalışan var mı? Eğer öyleyse, bu konuda bir fikir edinmek harika olurdu. DDD'nin doğru olması çok zor göründüğü için özellikle bazı başarı öyküleri dinlemek istiyorum.
Teşekkürler!