Tworzenie komponentów logicznych można podzielić na cztery etapy:
1. Identyfikacja głównych komponentów
2. Przypisywanie wymagań do komponentów
3. Analiza roli i odpowiedzialności
4. Analiza charakterystyk
Te etapy powinny być powtarzane przy dokonywaniu znaczących zmian w projekcie.
1. Identyfikacja głównych komponentów
Jest to punkt startowy – czyli mamy jakieś wymagania odnośnie aplikacji i trzeba stworzyć pierwszy szkic komponentów.
Są tutaj przynajmniej dwie heurystyki które mogą pomóc w uzyskaniu pierwszego szkicu komponentów: workflow oraz actor/action
Podejście workflow
Tutaj skupiamy się na przepływie pracy. Przykładowo:
1. Rejestracja użytkownika -> komponent Rejestracja użytkowników
2. Wybór ubezpieczenia -> komponent Market ubezpieczeń
3. Kupno ubezpieczenia -> komponent Sprzedaż
Więcej tutaj -> https://www.developertoarchitect.com/lessons/lesson192.html
Podejście actor/action
Tutaj skupiamy się na użytkowniku (osobie korzystającej z systemu) i akcjach przez niego wykonywanych. Przykładowo:
1. Użytkownik rejestruje się w systemie -> komponent Rejestracja użytkowników
2. Użytkownik wybiera ubezpieczenie -> komponent Market ubezpieczeń
3. Użytkownik kupuje ubezpieczenie -> komponent Sprzedaż
Więcej tutaj -> https://www.developertoarchitect.com/lessons/lesson193.html
[ANTYWZORZEC] Podejście podmiot na pierwszym planie (zwane The entity trap)
Tutaj skupiamy się na podmiotach. Przykładowo:
1. Użytkownik -> komponent Menedżer Użytkowników
2. Ubezpieczenie -> komponent Menedżer Ubezpieczeń
Prowadzi to najczęściej do zbyt dużych komponentów (posiadający zbyt wiele odpowiedzialności)
2. Przypisywanie wymagań do komponentów
Przeważnie dostajemy też od kogoś wymagania odnośnie aplikacji. Teraz czas aby te wymagania przypisać do wcześniej wybranych komponentów.
Załóżmy, że mamy takie wymagania jak:
– użytkownik ma mieć możliwość wykupienia dowolnej ilości ubezpieczeń -> komponent Market ubezpieczeń
– użytkownik ma mieć dostęp do wszystkich zakupionych ubezpieczeń -> komponent Moje ubezpieczenia
Jak widać, po przejściu przez wymagania powstał nowy komponent Moje ubezpieczenia.
3. Analiza roli i odpowiedzialności
Tutaj próbujemy przypisać rolę (wraz z odpowiedzialnościami) do komponentów aby sprawdzić czy komponent nie robi za dużo.
Weźmy na przykład komponent Market ubezpieczeń i przypiszmy mu odpowiedzialności:
– wyświetlanie dostępnych do kupienia ubezpieczeń
– umożliwienie wyboru wielu ubezpieczeń
– wyświetlanie szczegółów ubezpieczeń (TO WYDAJE SIĘ BYĆ JUŻ ZA DUŻO)
Do wyświetlania szczegółów ubezpieczeń najlepiej wydelegować oddzielny komponent – Szczegóły Ubezpieczeń.
4. Analiza charakterystyk
Teraz czas na charakterystyki. Załóżmy, że zleceniodawcom zależy najbardziej na wydajności.
To może spowodować, że przykładowo będziemy chcieli obsłużyć tylko podstawowe kwestie synchronicznie. A wystawimy asynchroniczną obsługę zapisu wszystkich danych potrzebnych do raportów – komponent Raportowanie Ubezpieczeń