Poprzednim razem dokonałem pewnej refleksji na temat mojej aplikacji schroniska dla zwierząt. Musiałem powiedzieć sobie dość i zaprzestać szukania “złotego środka” do tworzenia aplikacji. Zrobiłem uproszczone szkice aktualnego stanu aplikacji oraz funkcjonalności jakie chciałbym zaimplementować. Teraz pora spojrzeć na projekt z technicznego punktu widzenia. Więc jak podzielić tą aplikację?
Lista wszystkich wpisów dotyczących projektu AnimalShelter:
#1 - Opis projektu AnimalShelter
#2 - Pierwsze kroki w backendzie
#3 - Refactoring i prace rozwojowe części serwerowej
#4 - Tworzenie GUI w Angularze
#5 - Zatrzymaj się, przemyśl i zacznij działać!
#6 - Pomysł na architekturę
#7 - Wykorzystanie CQRS
#8 - Ponowna implementacja
#9 - Rozterki architektoniczne
#10 - Podsumowanie + implementacja wysyłki maili
#11 - Programowania ciąg dalszy
#12 - Dopinanie zadań do końca
Architektura AnimalShelter
Zdecydowałem się na dwa moduły: Użytkownika i CMS. Dla modułu Użytkownika chciałem zastosować CQRS, czyli w skrócie oddzielić zapis od odczytu. Oczywiście aplikacja zarządzająca schroniskiem nie wykorzysta całkowicie dobrodziejstw jakie niesie to podejście, ale da mi okazję do poćwiczenia tej koncepcji.
CQRS = oddzielenie zapisu od odczytu
Będzie możliwość wysłania formularza zgłoszeniowego wyrażającego chęć adopcji wybranego zwierzaka. Wydaje mi się, że nie będzie potrzebna rejestracja użytkownika, aby wypełnić taki formularz. Jednak muszę się nad tym jeszcze zastanowić. Ciekawym problemem może okazać się atomowości, którą trzeba będzie zapewnić na poziomie wysyłania komunikatu do CMS oraz wysyłania maili do pracowników schroniska. Są to asynchroniczne procesy, więc ciężej jest zachować integralność. Jeżeli mail zostanie wysłany, a komunikat do CMS nie to trzeba upewnić się, że przy ponownej wysyłce zostanie dostarczony tylko komunikat, aby użytkownik nie dostał dwóch maili. Mówił o tym Marcin Grzejszczak wraz z Kubą Pilimonem na jednej ze swoich prezentacji.
Co w CMS piszczy?
CMS okazuje się być zwykłym CRUDem, gdzie pracownicy będą mogli przeglądać zwierzaki, które znajdują się w schronisku. Oczywiście możliwe będzie też dodawanie nowych pupili, edytowanie informacji o nich czy też usuwanie ich w razie omyłkowego dodania. Jeżeli przyjmowany zwierzak okaże się być tym, który przekroczy bezpieczny limit miejsca w schronisku to zostanie wysłany mail do pracowników o tym wydarzeniu. Jest to funkcjonalność, którą chcę zachować z poprzedniej aplikacji - wspomniałem o tym w swoim pierwszym wpisie na temat tego projektu.
Nie chcę tworzyć też roli administratora systemu. Jeżeli zajdzie potrzeba dodania nowego pracownika do systemu będzie się to odbywało przy pomocy wcześniej przygotowanego skryptu SQL. Może ulegnie to zmianie w przyszłości, ale na ten moment nie chcę się nad tym bardziej pochylać.
Warto byłoby też poćwiczyć integrację z systemem zewnętrznym, więc do rozważenia zostawiam utworzenie prostej aplikacji działającej na boku. Mogłaby ona weryfikować czy zgłaszający się po zwierzaka nie jest posądzony o znęcanie się nad nimi. Jest to raczej abstrakcyjny twór, który na ten moment nie wiem jak mógłby wyglądać, ale fajnie byłoby mieć coś takiego do nauki.
Na koniec zostawiłbym sobie dodanie możliwości tworzenia PDFa przedstawiającego ogłoszenie adopcyjne konkretnego zwierzaka. Myślałem o jakiejś bibliotece umożlwiającej kreowanie czegoś takiego na podstawie HTMLa. Jednak jest to późny etap mojej aplikacji, dlatego na ten moment pozostanie to tylko w strefie rozważań. Na koniec warto jeszcze nadmienić, że przydałby się jakiś system sprawdzający na jakim etapie znajduje się dany proces adopcyjny, ale to również nie jest moim MVP.
Podsumowanie
Na papierze wygląda to naprawdę nieźle, ale napisany kod dopiero zweryfikuje do czego nadaje się to rozwiązanie. Mam nadzieję, że proces powstawania aplikacji nauczy mnie wielu rzeczy i poukłada obecną wiedzę. Nie pozostaje mi nic więcej jak tylko zakasać rękawy i brać się do roboty!