Czy używacie modułów w pracy?

0

Tak jak w tytule.W ogóle to jak najczęściej organizujecie kod?

0

Jeżeli chodzi o moduły wprowadzone w Javie 9: Nie spotkałem się. Generalnie ludzi ciężko jest przekonać do Nabrdalikowego package-scope'a by default i późniejszego wydzielania modułu do artefaktu. IMHO w ludziach zbyt silna jest moc controller/service/repository/model

2

Nie, ale...

Używam modułów kotlinowych. internal + public - mentalnie to samo co javowe (z punktu widzenia programisty). Ludzie w zespole spokojnie z tym żyli (chociaż modułów było od zarypania).

0

Nie, ale zamierzam. Tj. mamy taki JAR z własnymi funkcjami i operatorami dla niepoznaki nazwany utils. Napisany w Javie 8, będzie portowany na Javę 11 i zamierzam wrzucić żeby wpisując "My" w find class nie dostawać listy: MyProducer, MyProducerUtils, MyBusinessClassRelatedToProducerUtils etc.

Ale tak, internal z Kotlina byłoby lepsze.

0

Pracuję z OSGi, więc nie wiem, czy można to nazwać pełnoprawnymi modułami, ale jeśli tak, to tak, pracuję.

1

W środowisku javovym (zwłaszcza pre-9) najłatwiej wprowadzić moduły opakowując je w JARy i mavenowe moduły.
Technika tak stara, że nawet najstrarsze grzyby nie zauważą że mają moduły zamiast "starego dobrego" monolitu.
Co to w ogóle daje? Maven nie pozwala (AFAIK) na zależność cykliczną, więc zależności międzymodułowe przestają być przypadkowe i tworzy się DAG.

Można też połączyć obie koncepcje: https://www.baeldung.com/maven-multi-module-project-java-jpms

1

@MrMadMatt: Mylisz się. Jest trzecie wyjście, moim zdaniem najlepsze i myślę, że dość znane - package by feature. Dzięki takiemu podejściu masz uporządkowany kod według biznesowych pojęć np. główny folder Order a w nim domain,use cases, infrastructure, user interface i tak z każdym agregatem (np. Customer). W podejściu package scope Nabrdalika wszystko ląduje w jednym wielkim folderze domain, który prócz faktycznej domeny ma konkretne use casy, infrastructure w postaci jakiś interfejsów Spring Data, implementacje repozytoriów, kontener IoC, no ogólnie prawie wszystko tam jest, bo nie można tego uporządkować większą ilością folderów, bo o zgrozo więcej rzeczy będzie musiało być publiczne, ale to chyba wina Javy, bo sam pomysł jest zacny, żeby wystawiać tylko publiczną fasadę. Dużo lepiej jest to rozwiązane w C# gdzie można tworzyć oddzielne projekty w ramach jednej solucji dla poszczególnych warstw.

2

Tak - modułów mavenowych/gradlowych. Moim zdaniem nie da się inaczej wymusić separacji pomiędzy domeną i adapterami. Te pomysły że package scope coś tu załatwi to moim zdaniem marzenie ścietej głowy. Ja wole mieć po prostu moduł domain w którym ktoś musiałby explicite dodać jakąs zależność jakby chciał złamać separacje.

3

Większość z nas tutaj tworzy systemy klasy enterprise, czyli kolokwialnie mówiąc wewnętrzne CRUDy.
Natomiast moduły z Java 9 powstały dla fizycznego zabronienia korzystania z części wewnętrznej bibliotek typu open source. Mając tysiące zespołów korzystających z naszej libki, na pewno znajdzie się jeden kompetentny inaczej, i będziemy musieli utrzymywać legacy utilsy do końca świata. Dlatego wprowadzono drakońskie reguły enkapsulacji. Pewnie z frustracji, że w ekosystemie javy niczego nie da się zdeprecatować.
W naszych korporacjach zjawisko współdzielenia kodu też występuje, ale po prostu nie jest konieczny taki formalizm. Jest to wręcz kontrproduktywne.

Drugi argument przeciw modułom jest taki, że miały naprawdę słaby start. Do dzisiaj pamiętam godziny zmarnowane na walkę z modules+maven+legacy. Od tego czasu olewam tę technologię, tak jak od lat olewam przeglądarki Microsoftu. Może im się poprawiło, ale ja jeszcze nie jestem gotowy psychicznie na wybaczenie przeszłości.

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