Ja polecam - nie zaczynaj od modelowania w UML dziedziny - bo to przeważnie czysty nonsens i sztuka bezużytkowa. To dobrze wygląda na studiach i później ewentualnie w celu poniżania klientów.
(Nie kojarzę kiedy ostatnio widziałem diagram UML, który być chociaż trochę odpowiadał prawdzie... ( chyba, że to z reverse engineeringu był :-) ) Najważniejsze jest ustalenie wymagań. (przy okazji UseCase w UML to IMO kolejny nonsens- możesz olać ( Gdyby chociaż ludziki miały buzie to- można by im dorysowywać wąsy)).
Bo o ile to WEB to absolutnie najważniejszy jest Look and feel - UX.!
Jakie są strony, pociski, jak reagują itp.?. - i tu najlepiej "Pixel Genau" im dokładniej -> tym lepiej. Mało kto to robi (dobrze/w ogóle) - (bo to trudne !)- ludziki i strzałki rysuje się dużo łatwiej.
Pomocą do tego może być prześledzenie procesów i np. event storming (zależy czy to mała czy duża aplikacja).
Jak to zrobisz to reszta jest prosta.
To tyle jeśli chodzi o aplikację- jeśli jesteś architektem to musisz teraz zając się takimi rzeczami jak:
- testowalność systemu,
- budowanie zespołu,
- build,
- CI,
- technologie,
- narzędzia,
- wymagania niefunkcjonalne,
- security.
- konfiguracja,
- documentacja,
-hardware
I jeszcze w cholerę ... zależy od wielkości aplikacji, zespołu, budżetu itp.
Model obiektowy, dziedzina , sequence diagramy itp. ... przydają się w małej skali - zresztą książki raczej Cię tego nie nauczą (chyba, że jesteś wyjątkiem).
Jak nie wiesz co robić - to zrób prototyp. Najlepiej w moim życiu wyszły te projekty, które miały jakiś prototyp, POC itp. Często po kilkutygodniowym obrabianiu prototypu okazywało się, że klient to w zasadzie chce czegoś zupełnie innego - zupełnie innego niż opisane w 500 stronicowym zamówieniu z załącznikami. O wiele lepiej pracuje się przy czymś co widać, że sprawia radość użytkownikom i jest przez nich rozumiane niż wymyśloną przez analitykow kobyłę, której nawet programiści nie mogą ogarnąć. A dodatkowo z prototypu nawet biednego, w którym mnóstwo rzeczy jest pofejkowane czasem rodzą się dobre pomysły na architekturę.
I jeszcze - architektura to nie jest statyczna rzecz - zmienia się wraz ze zmianami w wymaganiach, zdobywaniem wiedzy i doświadczenia przez zespół. Czyli nie staraj się zaprojektować wszystkiego od początku do końca - bo i tak się nie uda. Raczej przygotuj się na stałe zmiany. Dlatego testowalność ,CI itp. są tak ważne.
A good architecture maximizes the number of decisions NOT made
Po tym wstepie przydługim rada praktyczna:
ściągnij jakiś przykład i analizuj jak działa.