Jak nazywa się taka architektura albo do jakiego jest podobna?
- Rejestracja:ponad 9 lat
- Ostatnio:ponad 5 lat
- Postów:56
Java - Rejestracja:ponad 11 lat
- Ostatnio:prawie 3 lata
- Postów:57
0
Wydaje mi się że to:
Architektura warstwowa
- Rejestracja:ponad 8 lat
- Ostatnio:około 2 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
8
Proponuje Secret architekture lub architektura nieśmiała. Patrzysz na top level pakiety i zupełnie nie wiadomo co aplikacja robi.
edytowany 1x, ostatnio: jarekr000000
- Rejestracja:około 7 lat
- Ostatnio:około 2 miesiące
- Postów:365
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
4
Na oko to wzorzec Generic CRUD.
- Rejestracja:około 11 lat
- Ostatnio:2 minuty
- Postów:8399
1
Dobrze, że ktoś to nazwał po imieniu
@yarel no... i to nie jeden odosobniony przypadek. Ciągle widzę, że ludzie mówią o "architekturze", a jedyne co mają na myśli tylko drzewko katalogów. A przecież to naprawdę nic nie mówi, bo:
- coś jak "config", w każdym projekcie jest pewnie
- "business" - często mianem "business logic"/logiką biznesową określa się totalnie wszystko, więc bez zajrzenia do środka możemy przypuścić, że będzie tam mnóstwo God Objectów
- "controller" - taka sama uwaga. Bardzo często ludzie do kontrolerów pakują wszystko.
- "service" - znowu, taka sama uwaga. Worek bez dna. Wszystko tam może praktycznie się znajdować, co nie pasuje gdzie indziej (czyli "tam żyją smoki").
- "repository" - jeszcze jeden modny wzorzec projektowy
- "validator" - tutaj widzimy przynajmniej obietnicę SRP, i o to mamy ładnie wydzielony katalog z walidacją... przynajmniej w teorii.
No i parę luźnych plików.
Application - pewnie punkt wejścia.
ErrorCode, ErrorMessage, Language - można łatwo się domyślić.
SendEmail - pytanie, czemu jest to luzem, a nie np. w "service" czy "business"?
Innymi słowy ciężko coś powiedzieć na temat architektury patrząc tylko na takie drzewko. Zgaduj-zgadula. Już lepszy byłby jakiś diagram zależności między poszczególnymi modułami. Wtedy byśmy widzieli, które moduły są przez które inne używane. Chociaż to też jeszcze i tak za mało, bo taki diagram i tak nie pokaże ci kontekstu, w jakim coś jest użyte, a tylko fakt zależności.
Z ciekawostek: pakiet
controller prawie na pewno nie zawiera kontrolera, ( w oryginalnym znaczeniu z MVC).
- Rejestracja:ponad 12 lat
- Ostatnio:około 2 godziny
- Postów:3540
0
To nie wzorzec, a raczej praktyka :)
Są dwa podejścia jeśli chodzi o packaging:
- by layer (controller, model, view, service) - sprawdza się w prostych apkach
- by feature (product, order, customer)
Tutaj masz bardziej to pierwsze, aczkolwiek business nie za bardzo wiem gdzie umieścić. Jeśli to JEE to faktycznie może mieć to jakiś sens, aczkolwiek sam wolę drugie podejście.
by feature właśnie jeszcze bardziej się sprawdza w małych
Źle napisałem, chodziło mi o to, że by layer może działać przy małych projektach, gdzie liczba feature'ów jest niewielka. Wtedy można sobie pozwolić, żeby np. mieć controller.ProductController i controller.CustomerController. Jeśli jednak takich kontrolerów jest dużo to się robi mały koszmar, bo trzeba skakać pomiędzy pakietami, a visibility każdej klasy z definicji musi być public.
0
- by layer (controller, model, view, service) - sprawdza się w prostych apkach
Dlatego, że proste apki mają jeden feature :)
Uważam, że nie ma żadnego znaczenia czy masz service.feature1 + service.feature2 czy feature1.service i feature2.service.
Skoro wszystko jest w jednym module i serwisy mają do siebie wzajemnie zależności, to raczej implementują jeden feature.
No chyba, chyba że nie mają wzajemnych zależności, bo się "umawiamy", że feature3 korzysta tylko z 2 i 1, a 2 tylko 1, a 1 z żadnego innego.
Jeśli faktycznie mówimy o osobnych "ficzerach" to chyba one powinny mieć takie zależności między sobą?
Jeśli powinny mieć takie zależności to raczej powinny być budowane jako osobne moduły z zależnościami zdefiniowanymi wprost a nie z umowy na gębę (bo wtedy narzędzia będą dbały o to, żeby nie robić spaghetti zależności).
Jeśli mamy feature w osobnych modułach ze zdefiniowanymi zależnościami... to znowu nie ma znaczenia czy jest feature1.service czy service.feature1 w nazwie pakietu, bo feature jest określony w nazwie modułu.
0
Według mnie powinno dążyć się do pakiet = moduł, a moduł to zbiór funkcjonalności z jedną publiczną fasadą, a reszta schowana w pakiecie
Na temat rozdrobnienia modułów już nie mam zdania, chodziło mi tylko o to, że albo definiujemy jakieś zależności (kto kogo używa) albo ich nie definiujemy.
Jak definiujemy to IMHO trzeba mieć te zależności jawnie spisane i przestrzegane (i wtedy nazwy pakietów w środku modułu mają mniejsze znaczenie)
Jak nie definiujemy to nazwy pakietów nie mają znaczenia, bo wszystko może wołać wszystko i nie ma co udawać jakiekolwiek organizacji.
- Rejestracja:ponad 6 lat
- Ostatnio:prawie 6 lat
- Postów:4
0
Kolejna osoba, która nie była na bootcampie... Pakiety nazywamy "by feature", a to na zdjęciu to g0wn0.