Myślałem o tym jakiś czas temu i niedawno pojawił się ponownie, ponieważ mój sklep tworzy swoją pierwszą prawdziwą aplikację internetową w języku Java.
Jako wprowadzenie widzę dwie główne strategie nazewnictwa pakietów. (Żeby było jasne, nie odnoszę się do całej części tego „domena.firma.project”, mówię o konwencji pakietu poniżej.) W każdym razie, widzę konwencje nazewnictwa pakietów:
Funkcjonalne: nazywanie pakietów zgodnie z ich funkcją architektoniczną, a nie ich tożsamością zgodnie z domeną biznesową. Innym terminem na to może być nazywanie według „warstwy”. Tak więc miałbyś pakiet * .ui, pakiet * .domain i * .orm. Twoje pakiety to poziome plasterki, a nie pionowe.
Jest to znacznie częstsze niż nazewnictwo logiczne. Właściwie nie wierzę, żebym kiedykolwiek widział lub słyszał o projekcie, który to robi. To oczywiście sprawia, że jestem nieufny (trochę tak, jakbyś pomyślał, że znalazłeś rozwiązanie problemu NP), ponieważ nie jestem zbyt mądry i zakładam, że każdy musi mieć świetne powody, aby robić to tak, jak robią. Z drugiej strony nie sprzeciwiam się temu, by ludzie po prostu tęsknili za słoniem w pokoju i nigdy nie słyszałem prawdziwego argumentu za takim nazewnictwem paczek. Po prostu wydaje się, że jest to de facto standard.
Logiczne: nazywanie pakietów zgodnie z tożsamością domeny biznesowej i umieszczanie w tym pakiecie każdej klasy, która ma do czynienia z tym pionowym wycinkiem funkcjonalności.
Nigdy o tym nie widziałem ani nie słyszałem, jak wspomniałem wcześniej, ale ma to dla mnie mnóstwo sensu.
Zwykle podchodzę do systemów w pionie, a nie w poziomie. Chcę wejść i rozwijać system obsługi zamówień, a nie warstwę dostępu do danych. Oczywiście istnieje duża szansa, że podczas tworzenia tego systemu dotknę warstwy dostępu do danych, ale chodzi o to, że nie myślę o tym w ten sposób. Oznacza to oczywiście, że kiedy otrzymuję zlecenie zmiany lub chcę zaimplementować jakąś nową funkcję, byłoby miło nie musieć wędrować w grupie pakietów, aby znaleźć wszystkie powiązane klasy. Zamiast tego po prostu zaglądam do pakietu X, ponieważ to, co robię, ma związek z X.
Z punktu widzenia programisty uważam, że główną zaletą jest dokumentowanie przez pakiety domeny biznesowej, a nie architektury. Wydaje mi się, że domena jest prawie zawsze tą częścią systemu, która jest trudniejsza do zrozumienia, gdzie architektura systemu, zwłaszcza w tym momencie, staje się prawie przyziemna w jego implementacji. Fakt, że mogę dojść do systemu z tego typu konwencją nazewnictwa i od razu z nazewnictwa paczek wiem, że zajmuje się on zamówieniami, klientami, przedsiębiorstwami, produktami itp. Wydaje się cholernie przydatny.
Wygląda na to, że pozwoliłoby to znacznie lepiej wykorzystać modyfikatory dostępu Javy. Pozwala to na znacznie bardziej przejrzyste definiowanie interfejsów w podsystemach, a nie w warstwach systemu. Więc jeśli masz podsystem zamówień, który chcesz, aby był przezroczysty trwały, teoretycznie możesz po prostu nigdy nie pozwolić nikomu innemu wiedzieć, że jest trwały, ponieważ nie musisz tworzyć publicznych interfejsów do jego klas trwałości w warstwie dao i zamiast tego pakować klasę dao w tylko z zajęciami, którymi się zajmuje. Oczywiście, jeśli chcesz ujawnić tę funkcjonalność, możesz zapewnić jej interfejs lub upublicznić. Po prostu wygląda na to, że wiele z tego tracisz, dzieląc pionowy fragment funkcji systemu na wiele pakietów.
Przypuszczam, że jedną wadą, którą widzę, jest to, że sprawia, że zrywanie warstw jest trochę trudniejsze. Zamiast po prostu usunąć lub zmienić nazwę pakietu, a następnie upuścić nowy w miejscu z alternatywną technologią, musisz wejść i zmienić wszystkie klasy we wszystkich pakietach. Jednak nie widzę, żeby to była wielka sprawa. Może to wynikać z braku doświadczenia, ale muszę sobie wyobrazić, że ilość razy, kiedy wymieniasz technologie, blednie w porównaniu z ilością razy, kiedy wchodzisz i edytujesz pionowe wycinki funkcji w swoim systemie.
Więc myślę, że wtedy padłoby pytanie, jak nazwać swoje paczki i dlaczego? Proszę zrozum, że niekoniecznie myślę, że natknąłem się na złotą gęś czy coś tutaj. Jestem całkiem nowy w tym wszystkim, mając głównie doświadczenie akademickie. Jednak nie mogę dostrzec luk w moim rozumowaniu, więc mam nadzieję, że wszyscy to potrafią, abym mógł przejść dalej.