Spring clean architecture

Odpowiedz Nowy wątek
2019-08-10 21:10
1

Cześć,
Zacząłem ostatnio tworzyć projekt którego głównym celem jest zapoznanie się z architekturą heksagonalna, separacją logiki domenowej od frameworka (Spring) oraz poznanie biblioteki Vavr
Funkcjonalnie ma to być Internetowy dziennik treningowy, czyli układanie treningów / diety, śledzenie swoich postępów, itp. Póki co jednak nic z tego nie jest ruszone, zacząłem od modułu użytkownika który obecnie umożliwia rejestracje i potwierdzenie założenia konta.
Po stronie infrastruktury, skonfigurowane jest security na podstawie JWT oraz połączenie do MongoDB.
Obecnie siadam do frontendu (Angular) i bardzo zależałoby mi na review tego co obecnie napisałem.

https://gitlab.com/angryprogrammer01/springcleanarchitecture

Pozostało 580 znaków

2019-08-13 20:01
1

Wygląda to naprawdę nieźle! :) z plusów:

  1. klasy package scope
  2. podział na pakiety per feature
  3. zastosowanie dependency inversion principle.
  4. kod jest czytelny
  5. testy jednostkowe przez fasadę, a nie na wszędobylskich mockach

Nad czym bym się zastanowił:

  1. Brak testów integracyjnych - skąd wiesz, że Twoja aplikacja zadziała na produkcji?
  2. Klasa ResponseResolver - użyj @ControllerAdvice
  3. Jest kilka „worków”, które mogą się rozrastać - np. ten ObjectCreator w testach, czy pakiet „common” - tutaj możesz zrobić podpakiet „vavr” na extensiony stricte dotyczące Vavra
  4. Brak struktury given/when/then testów (lub arrange/act/assert), przez co są nieczytelne i sprawdzają za dużo. Brakuje mi tez testów na ścieżki alternatywne - widać, że nie robisz TDD.
  5. Kolizja nazwy klasy ObjectMapper. Wiem, że to domena i nie wie o Springu, natomiast jest to i tak mylące. Poza tym nazwa aby ogólna, proponuję UserConverter.
  6. Nie podoba mi się, że fasadę do testów tworzysz inaczej niż produkcyjną - testowa metoda powinna wołać produkcyjna, abyś testował kod, który będzie odpalany na prodzie.
  7. Jeden kontroler i fasada zarówno do pobierania zasobu Usera, jak i do jego rejestracji i linków aktywacyjnych - te ostatnie nie są raczej zasobami w rozumieniu REST oraz będą miały pewnie inne reguły security. Rozważyłbym rozwód kontrolerów, moduł może zostać jeden.

Na zakończenie powtórzę - jest nieźle! :)

edytowany 3x, ostatnio: Charles_Ray, 2019-08-13 20:09

Pozostało 580 znaków

2019-08-13 23:52
0

@Charles_Ray: co do punktu 6, czyli tworzymy Fasadę tą samą metodą w Configuration, ale po prostu przekazujemy tam w parametrach nasze implementacje InMemory?

Pozostało 580 znaków

2019-08-13 23:55
0

@weiss: w testach możesz od razu zrobić new XFacade(cosInMemory, cosInMemory) bez potrzeby konfiguracji itp. Klasy Configuration są zazwyczaj tylko na potrzeby spięcia całości frameworkiem itp


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
edytowany 1x, ostatnio: danek, 2019-08-13 23:55

Pozostało 580 znaków

2019-08-14 00:02
0

Czyli klasa Configuration przyda się nam jeśli będziemy z Fasady musieli zrobić Bean żeby mógł on tam podpiąć swoje adnotacje potrzebne do działania. Czyli np. przekazujemy Springowej DAO?

mniej więcej - danek 2019-08-14 00:13

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0