Packages i ich podział

Przechodząc z C++ do Javy nie bardzo rozumiałem pojęcie paczek (pakietów, packages, jak zwał tak zwał). Po styczności z komercyjnym kodem w pierwszej pracy myślałem, że pojąłem o co chodzi. Przykładowo: **dto **- a w niej klasy obiektów transferowych, entities- encje zapisywane na bazie, **translators ** - entityToDtoTranslator, **controllers ** - wiadomo.
Tak samo były skonstruowane wszystkie poradniki (głównie mowa o Springu) na które trafiłem. Do czasu aż obejrzałem to

Czyli wszystko powyższe to błąd? Powinno się bardziej skupiać na stworzeniu samowystarczalnej paczki która sama przynosi jakąś funkcjonalność?
Pomyślałem więc o prostym przykładzie - logowanie do serwisu.
W skrócie: signInController -> signInValidator -> accountFacade -> accountRepository -> accountEntity, czyli spoko mamy paczkę która sama w sobie potrafi przejeść przez proces logowania, możemy wszystkie klasy poza fasadą całkowicie zamknąć na świat (wszystkie metody package-scoped). No ale jak jest logowanie, musi być i rejestracja, teoretycznie wystarczy dopisać registerController i registerValidator i podpiąć go pod accountFacade, jednak wtedy nie mamy już jednej samowystarczalnej paczki, jest ona zależna od innej. Czyli co teraz? Zamykamy całość w jeden moduł/pakiet? Czy stosujemy jakieś inne podejście?

W tym wypadku mógłbyś zamknąć całość w jeden moduł pakiet - bounded context. Btw walidacje bym robił za fasadą, a nie przed. Generalnie nie myśl o use case'ach typu logowanie, rejestracja tylko pomyśl o module jako całości. Czy zalogowanie użytkownika i jego rejestracja nie wpisują się w możliwe akcje dla obiektu/modułu konto?

Emdzej93 napisał(a):

Przechodząc z C++ do Javy nie bardzo rozumiałem pojęcie paczek (pakietów, packages, jak zwał tak zwał). Po styczności z komercyjnym kodem w pierwszej pracy myślałem, że pojąłem o co chodzi. Przykładowo: **dto **- a w niej klasy obiektów transferowych, entities- encje zapisywane na bazie, **translators ** - entityToDtoTranslator, **controllers ** - wiadomo.
Tak samo były skonstruowane wszystkie poradniki (głównie mowa o Springu) na które trafiłem. Do czasu aż obejrzałem to

Wiesz nie zdziw się, ale większość poradników na internecie i większość projektów komercyjnych nie ma wysokiego poziomu. Kluczem tutaj jest to żebyś umiał oddzielić i przefiltrować te dobre ziarno poradników od złych praktyk. Tutaj akurat trafiłeś na materiał na bardzo wysokim poziomie - i tak - tak jest, że tutaj ten gość mówi dobrze jak to powinno być zrobione a w twojej pracy robią źle. Być może gdybyś im to powiedział to kłóciliby się z Tobą wszyscy wraz z głównym architektem - ale to zależy od poziomu twojego pracodawcy. Powinno się dzielić na pakiety i moduły tak jak ten człowiek prawi a nawet - to jest najprostszy i najłatwiejszy krok w stronę podziału w przyszłości aplikacji na moduły / współgrające ze sobą mikroserwisy. Moim zdaniem zacznij indoktrynację w swoim miejscu pracy pokazując im filmik tego gościa a jak to nie pomoże to ten wątek tutaj na forum.