Witam,
poszukałem trochę po sieci i nie bardzo widzę odpowiedź na moje pytanie. Mógłby ktoś z doświadczeniem podzielić się po krótce w jaki sposób tworzy się dokumentacje DDD do aplikacji? W jakim programie, jakie są dobre praktyki, praktyczne wskazówki, wypracowane rozwiązania... Programuję od lat, jakieś tam mniejsze dokumentację piszę, ale czas podnieść poprzeczkę :)
0
0
Dobry kod sam się dokumentuje. UML bywa też niekiedy pomocny.
Jaki jest cel dokumentacji, o którą pytasz?
0
Dobry kod się sam dokumentuje, ale żeby taki napisać trzeba temat przeanalizować, a całego systemu w głowie nie ogarną na raz - stąd potrzeba dokumentacji.
Po drugie po roku, dwóch, trzech - nie chciałbym przeglądać setek linii kodu, aby zrozumieć logikę systemu. Nie chciałbym też, aby nowe osoby pracujące przy kodzie musiały się domyślać logiki po kodzie.
Główny cel dokumentacji, o którą pytam to planowanie produktu. Zanim zacznę pisać, chcę mieć z grubsza plan co, gdzie, w jaki sposób i dlaczego będzie działać. Nie chcę pisać "na pałę", a potem marnować czasu na zmianę w całym systemie, bo po 3 miesiącach przypomnę sobie o czymś co zmieni całą logikę.
Z systemami bez planu i odpowiedniej dokumentacji miałem już do czynienia, do tego źle zarządzanymi - nie chciał bym powtarzać czyiś błędów.
Czy to wystarczające powody do zrobienia dokumentacji? :)
0
I czy UML, który uprzednio zaproponowałem, jest niewystarczający?
0
A tego nie wiem, dlatego pytam :) Powtórzę:
"Mógłby ktoś z doświadczeniem podzielić się po krótce w jaki sposób tworzy się dokumentacje DDD do aplikacji? W jakim programie, jakie są dobre praktyki, praktyczne wskazówki, wypracowane rozwiązania..."
Może macie jakiś przykład takiej dokumentacji?
2
Główny cel dokumentacji, o którą pytam to planowanie produktu. Zanim zacznę pisać, chcę mieć z grubsza plan co, gdzie, w jaki sposób i dlaczego będzie działać.
To sie nazywa Waterfall i już kilkadziesiąt lat temu okazało sie że nie działa zbyt dobrze ;)
0
Ale... nie muszę stricte stosować danej metodologii. Dla mnie najważniejsze, żeby w jakiś sposób spisać logikę systemu, zanim zacznę go programować. I wydaje mi się, że "sposób myślenia DDD" będzie najlepszy. Pytanie w jaki sposób zapisać efekt planowania, przemyśleń. Chyba nie powiecie, że mam nie robić wcale dokumentacji? :D Ktoś z Was ma doświadczenie z dokumentacją DDD? W czym ją zapisywać i jak? Przykłady?
0
Jak tak bardzo chcesz to poczytaj sobie http://wwwis.win.tue.nl/2R690/doc/ECSS-E-ST-40C(6March2009).pdf w appendixach masz dość szczegółowe szablony dla każdego rodzaju dokumentu :)
0
DDD to sposób łączenia obiektów w programie, więc naturalne wydają się diagramy klas. W celu opisania procesów biznesowych w ramach tych klas mogą się przydać diagramy aktywności. W celu opisu współpracy między poszczególnymi warstwami przydatne są diagramy sekwencji. A funkcjonalność systemu z punktu widzenia użytkownika można opisać diagramami przypadków użycia. Każdy z tych diagramów jest diagramem UML. Ta notacja jest dość rozsądnym rozwiązaniem - no chyba, że ktoś zamiast prostych rysunków woli produkować kupę tekstu, którego nikt nigdy nie przeczyta.
0
No i teraz jestem troszeczkę mądrzejszy :) Dzięki. Resztę doszukam, doczytam, chyba, że macie jeszcze jakieś rady.
Co do tekstu - oczywiście niezbędne minimum. Nawet nie chodzi o niechęć do czytania, bardziej o niechęć do aktualizacji stosu dokumentacji. A nieaktualna dokumentacja jest chyba nawet gorsza od jej braku.