Alan adı odaklı tasarımda yeniden düzenleme [kapalı]


10

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!


Boyutu ne olursa olsun değiştiremeyeceğinizi düşünmediğiniz bir kod yazıyorsanız, durun.
JeffO

@Jeff: Bunu değiştirememe meselesi değil, kod eklendikçe onu değiştirmek için gerekli olan zaman ve kaynaklar meselesi.
Andrew Whitaker

2
Mevcut kodun yeniden düzenlenmesi gerektiğini bilen bir kod ekliyorsanız ve istemiyorsanız, risk alıyorsunuz demektir. Bu işe yaramayacağı anlamına gelmez.
JeffO

Yanıtlar:


9

Bir süredir DDD'nin büyük bir hayranıydım (bir test çerçevesinin güvenlik ağı olan ve olmayan).

Yeniden düzenleme kavramının tamamı ve yaşam döngüsü değişmiyor çünkü artık yeni bir tasarım yöntemi kullanıyorsunuz. Önemli bir zaman alacaksa, yönetimden bu zamanı alabilmek için projeye orantılı bir faydası olmalıdır.

Bunu yapmakla ilgili olarak: bir örnekte, etki alanı modelinin anlaşılmasındaki bir 'atılım' nedeniyle 3 aylık bir büyük yeniden düzenlemeye katıldım. Mevcut davranışı doğrulamak için testler, beklenen davranışı doğrulamak için testler ve arama kodunda değişiklikler yapılması gerekiyordu. Ancak faydalar önemliydi ve işletmenin daha önce yapması gereken, ancak yapamadığı çok daha fazla şey yapmasına izin verdi. Özünde, yeniden düzenleme esasen bir 'özellik'ti.


Böyle büyük bir refactor yapmayı başardığınızı duyduğuma sevindim. Başlamak için böyle büyük bir değişiklik yapmanız gerektiğini duymak da güzel. Bahsettiğim bir tür refactor bu. Aylar boyunca büyük etkisi oldu.
Andrew Whitaker

Bir özellik olarak yeniden düzenleme hatırlayacağım bir özellik.
Filip Dupanović

5

Etki Alanına Dayalı Tasarımda Yeniden Düzenleme Bir ihtiyaçtan kaynaklandığını düşünüyorum, "hoş" bir yeniden düzenleyici değil. Yanlış bir Etki Alanı Modeli belirlediğiniz anda, kod / sistem gerçek dünya sorununu temsil etmez.

Durumda, son zamanlarda makul bir alan karmaşıklığı uygulaması üzerinde çalıştık. Bu bir Faturalandırma / Sözleşme sistemiydi ve yeni bir oran getiriyoruz. Çevik bir süreç kullanıyorduk, hassas olmak için 2 haftalık scrums kullanıyorduk.

Başlangıçta modelde 2 oranın tamamen ayrı olduğunu ve Sözleşme dışında bir ilişkisi olmadığını belirledik. Ancak daha fazla hikaye tamamladığımızda, aslında aynı olduklarının farkına vardık, özellikle yeni oranı sadece işe almak için eski bir oran olarak sarmaya başladığımızda. Bu ilk uyarı işaretiydi.

Hikayeyi kısaltmak için, hikayelerin% 90'ını yanlış modelle yapmayı başardık, ancak kodun her bölümünde yeni Oranı eskisi olarak sarmaladığımız ve / veya newRate else oldRate HER durumda. Başımızı meşhur brickwall'a vuruyorduk. Projenin bu kısmında yarı yolda kalmıştık ve tamamlanma zamanının yanlış etki alanı modeliyle üstel veya işe yaramayacağını biliyorduk. Bu yüzden mermiyi ısırdık, bir hikayeyi diğer sekiz hikayeye ayırdık ve Alan Modeli'ni yeniden düzenledik.

Projeyi tamamladığımızda, geziden yapılması gereken doğru şey olduğunu ve doğru yapmak için yapılacak tek şey olduğunu biliyorduk.

Zaman aldı mı? Evet, ama yapmasaydık daha fazla zaman alacaktı. DDD doğru mu yapıldı? Eh, tuhaf bir şekilde DDD hakkında o zaman bilmiyorduk, ama Eric Evans tarafından bir DDD atölyesine katıldıktan kısa bir süre sonra ve ben ve arkadaşlarımın yapabileceği tek şey başını sallamak. Bence DDD'yi bilseydik, refactoru daha erken alırdık, böylece daha fazla zaman kazanırdık.


Mükemmel cevap. Birkaç ayda bir buna benzer bir şeyden geçiyoruz. Yalnız olmadığımızı bilmekten memnunum!
Andrew Whitaker

3

Etki Alanı Modeli'nde yanlış bir şey alırsanız düzeltmeniz önemlidir. Deneyimlerime göre, bazılarını uyguladığımızda alan modelinin farklı varlıklara nasıl bağlandığını biraz kaçırdık.

Bunun sonucu, insanların eskisi için kullanılmadığı şekilde modelleme yapması ve dolayısıyla modelin "işe koyulmasını" denemek için diğer bölümlerini kırmasıydı.

Etki alanı modelinde bir sorun olduğunu fark ettiğiniz anda mümkün olduğunca hızlı değiştirin. Refactor etmeden önce ne kadar uzun sürerse, şimdi zihinsel modeller adapte edilen kullanıcılara göre değiştirmek daha zor olacaktır.


3

Kodun bazı bölümleri için sürekli yeniden düzenleme aşırı doldurulur. Kodun başka bir kısmı için (DDD'de, Temel Etki Alanı olarak adlandırılır ) bir zorunluluktur. Kodun nasıl olması gerektiğini anlamak, geliştiriciye ek bir bilişsel yük yerleştirir (etki alanını anlama ve mevcut uygulama arasındaki fark), daha sonraki gelişmeleri daha zor ve / veya pahalı hale getirecektir.

Soru şudur: "bu evrime ihtiyaç olacak mı?". Çekirdek Etki Alanında (iş farkını yaratan alan) cevap "Evet!" Çünkü bu, işletmenin daha fazla endişe duyduğu ve paydaşlar için fark yaratacak alanın iksiri. Etki Alanı Modelinizin esnekliği nedeniyle, bir sonraki gereksinimi minimum çabayla uygulamaya hazır, kodunuzu mükemmel durumda tutmak istediğiniz yerdir.

Ancak, tüm uygulama kodlarına uygulandığında bu pahalı olacaktır . İş için bu kadar önemli olmayan alanlar ( DDD dilimi için Destekleyici veya Genel Alt Etki Alanları ), çekirdek için ayrılmış olandan daha az karmaşık bir yaklaşım gerektirebilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.