A ja nie rozumiem, czemu taki nacisk na uml? To tylko technika projektowania. W zależności od tego, co będziesz robić są jeszcze chociażby mockupy - do projektowania interfejsów graficznych.
Dobra, widzę, że wiesz iż projektowanie jest ważne. Nie wiesz tylko pewnie dlaczego i w jaki sposób łączyć to z programowaniem.
Jeśli naprawdę interesujesz się tym zagadnieniem, powinieneś rozpocząć od czegoś takiego jak Use Case i User Stories.
Use Case czyli przypadki użycia - różne elementy twojego programu w różny sposób będą używane. Powinieneś już na początku przynajmniej część z tych rzeczy znać.
User Stories - to coś podobnego do powyższego, ale to są historyjki użytkownika, które opisują zachowanie użytkownika w czasie korzystania z aplikacji.
W sumie w zakresie tych dwóch pojęć kryje się ocean innych. Czemu? Najpierw musisz utworzyć wspólny język dla wszystkich komponentów. Musisz się zastanowić, czy lepiej nazwać encję User, czy może Account, czy może Customer. A może w różnych miejscach sa potrzebne różne nazwy? Jeśli tak to potrzbujesz zarówno encji User, jak i np Account - i są one od siebie niezależne bo występują w różnych kontekstach.
W tym znajduje się także takie pojęcie jak event storming, czyli całe planowanie zdarzeń występujących w aplikacji.
Mega skrócony opis:
- opisz dziedzinę za pomocą rzeczowników i czasowników. To będzie wynikać z use cases i user stories. Po prostu wyciągasz z nich te elementy.
- rozdziel je na dwie grupy
- zrób event storming
- teraz opiszę część tego co nie skumasz jeszcze: podziel te wszystkie elementy na encje i value-objects. Encje mają swoją tożsamość i można je zidentyfikować - są unikalne.
- Następnie wśród encji wybierasz te, które mogą być agregatami a z nich wybierasz te, które mogą być korzeniami agregatów.
- Później planujesz tworzenie fabryk
- dzielisz aplikację na moduły/pakiety
- projektujesz dalej...
I tak to nie jest wszystko. Generalnie jeśli samo projektowanie aplikacji Cię interesuje to polecam Eric Evans - Domain-Driven Design.
Jest kilka "ale". Jest to książka trudna w odbiorze nawet dla osoby doskonale znającej paradygmaty obiektowe. Nie ma tam zbyt wiele kodu i czytając, nudzisz się. Dopiero po jakimś czasie doceniasz wiedzę z niej. Po drugie, jest to książka dotycząca wytwarzania oprogramowania generalnie - nie gier. Gry w nieco inny sposób się tworzy, ponieważ to nieco inna gałąź programowania. Chociaż - to moje osobiste zdanie - świat byłby piękniejszy, gdyby programiści c++ potrafili wzorce przynajmniej tak dobrze, jak potrafią prawić godzinami o wyższości ++i nad i++.
Jeśli chodzi o projektowanie:
http://cocoders.com/cocoders-flow-specyfikacja-i-projektowanie-domeny-poprzez-przyklady/
http://bottega.com.pl/artykuly-i-prezentacje
http://helion.pl/ksiazki/domain-driven-design-zapanuj-nad-zlozonym-systemem-informatycznym-eric-evans,domdri.htm
http://helion.pl/ksiazki/tdd-sztuka-tworzenia-dobrego-kodu-kent-beck,tddszt.htm
http://helion.pl/ksiazki/testy-jednostkowe-swiat-niezawodnych-aplikacji-wydanie-ii-roy-osherove,tesjed.htm
http://helion.pl/ksiazki/zwinne-wytwarzanie-oprogramowania-najlepsze-zasady-wzorce-i-praktyki-robert-c-martin,zwiwyo.htm
A już w ogóle generalnie, to zainwestuj w którekolwiek z tych pozycji:
https://php-kurs.gitbooks.io/phpkurs/content/bibliografia.html Szczególnie, gdy jest mowa o refaktoryzacji, domain driven design, models, tdd, bdd, design patterns czy wzorcach.
