Czy tak podział na pakiety jest ok czy można by to zrobić lepiej? Jak wy w ogóle dzielicie?
- Rejestracja:ponad 2 lata
- Ostatnio:około 19 godzin
- Postów:135
0
- Rejestracja:około 17 lat
- Ostatnio:około 9 godzin
- Lokalizacja:Wrocław
0
W jednej aplikacji UI i domena? To jakiś desktop?
Klaun
Może stary dobry server-side rendering a nie jakieś SPA pchane na siłę ;)
.GodOfCode.
@Klaun: na SPA trzeba się więcej namęczyć, jednak jak serwer od razu konkretne dane zwraca to ta hydratacja, nie trzeba specjalnie restami pobierać danych i potem struktur uzupełniać co jest mega męczące w SPA. Takie diango czy nextjs wszystkie serwer side renderingi to Jest o conajmniej 50% łatwiej tą stronę wykonać, bo nie trzeba w jsie męczyć się z uwierzytelnianiem i pobieraniem danych i ich wizualizacją.
- Rejestracja:ponad 2 lata
- Ostatnio:około 19 godzin
- Postów:135
0
somekind napisał(a):
W jednej aplikacji UI i domena? To jakiś desktop?
UI w sensie REST API xd
- Rejestracja:ponad 13 lat
- Ostatnio:około 2 miesiące
- Postów:342
0
Ja wole podział w stylu:
Domain
- User
- Expense
Application
(tutaj jakieś pakiety)
Infrastructure
(tutaj jakieś pakiety)
Api / UI itd
(tutaj jakieś pakiety)
Innymi słowy: warstwy takie jak Domain, Application, Infrastructure i API powinny być wyżej w hierarchii niż pakiety "User" czy "Expense". W takiej sytuacji każda warstwa (Domain, Application, Infrastructure i API) może być osobnym projektem. Można też zdefiniować zależności między tymi projektami w taki sposób aby utrudnić proces powstawania tzw. cieknących abstrakcji. Jeżeli ustawisz zależności między projektem Domain i Infrastructure tak aby pliki projektu Infrastructure nie były dostępne z poziomu projektu Domain to wtedy trudno jest mieszać kod domeny z kodem infrastruktury.
- Rejestracja:około 17 lat
- Ostatnio:około 9 godzin
- Lokalizacja:Wrocław
1
tk napisał(a):
Innymi słowy: warstwy takie jak Domain, Application, Infrastructure i API powinny być wyżej w hierarchii niż pakiety "User" czy "Expense".
Wyżej powinny być domeny, niżej warstwy aplikacji.
W takiej sytuacji każda warstwa (Domain, Application, Infrastructure i API) może być osobnym projektem.
W jakim sensie projektem?
- Rejestracja:ponad 13 lat
- Ostatnio:około 2 miesiące
- Postów:342
0
somekind napisał(a):
tk napisał(a):
Innymi słowy: warstwy takie jak Domain, Application, Infrastructure i API powinny być wyżej w hierarchii niż pakiety "User" czy "Expense".
Wyżej powinny być domeny, niżej warstwy aplikacji.
Rozwiń myśli ponieważ nie wiem czy się dobrze rozumiemy
W takiej sytuacji każda warstwa (Domain, Application, Infrastructure i API) może być osobnym projektem.
W jakim sensie projektem?
Z tego co kojarzę to jesteś dotnetowcem, więc biorąc pod uwagę wynalazki Microsoftu możesz sobie to wyobrazić jako utworzenie powiedzmy solucji "System" a w niej czterech projektów o nazwie "Domain", "Application", "Infrastructure" i np. "Api". Oczywiście nie narzucam takiego podziału jako jedyny słuszny. Nie jest też tak, że krytykuje podejście zaproponowane przez autora posta (ma swoje plusy i niekoniecznie trzeba z niego rezygnować). W sumie to dużo zależy od konkretnego przypadku.
Do autora postu: czy Ty planujesz robić jakieś oprogramowanie, które z założenia chcesz rozbijać na mikrousługi?
edytowany 6x, ostatnio: tk
- Rejestracja:około 17 lat
- Ostatnio:około 9 godzin
- Lokalizacja:Wrocław
1
tk napisał(a):
Rozwiń myśli ponieważ nie wiem czy się dobrze rozumiemy
Z tego, co widzę w pierwszym poście, to @Nofenak ma dwie domeny: expenses i users, i je dzieli na warstwy. Dzięki temu każda z tych dwóch domen może być niezależnie wdrażanym modułem systemu. Czy taki jest cel, ani czy to ma sens, to nie wiem, bo w sumie poza screenem nie mamy podanych wymagań.
Z tego co kojarzę to jesteś dotnetowcem, więc biorąc pod uwagę wynalazki Microsoftu możesz sobie to wyobrazić jako utworzenie powiedzmy solucji "System" a w niej czterech projektów o nazwie "Domain", "Application", "Infrastructure" i np. "Api".
No ok, tylko w ten sposób powstanie monolit, w którym wszystkie domeny będą wymieszane ze sobą.
Nie mówię, że to zawsze źle, ale to jakby w niewielu przypadkach ma zalety. Mnie osobiście bardziej podoba się podział na domeny, a potem na warstwy.
W sumie to dużo zależy od konkretnego przypadku.
Pełna zgoda, póki co za mało wiadomo.
"No ok, tylko w ten sposób powstanie monolit" - dlatego właśnie chciałem zapytać autora czy myśli o mikro usługach. Jeżeli autor chce tworzyć jakiś projekt, który później będzie rozbijał na mikro usługi to podejście rozbicia na domeny a później na warstwy wydaje się być znacznie lepszy (w większości przypadków). W przypadku monolitów to już można dyskutować ale chyba nie ma sensu.
No chyba się nie dowiemy, bo od paru dni autor nic nie odpisał.
1
Jeśli miałbym komuś coś polecić, to nie sugeruję robić matrycy - czyli np. warstwy x products albo products x warstwy. Ja zrobiłbym podział:
ui/
infrastructure/
application/
expenses/
users/
Od razu odpowiadam na pytania: "Eee rydel a co jak mam kod zarówno związany z users/ i ui/?". Poprawna odpowiedź brzmi: należy użyć swoich skilli designowych, i rozdzielić swój use-case na dwa, osobno na ui/ i osobno na users/ (innymi słowy zrobić separation of concerns). Część userową włożyć do users/, część uiową do ui/. I od razu pociągnę kolejny temat: "ee ale to przestanie wyglądać wtedy jak w przykładach w dokumentacji frameworka 
" - tak. W większości przykładów frameworków prezentowany design nie jest za dobry.
Owszem, nie wygląda to "tak jak wygląda w większości firm", ale też "w większości firm" ludzie narzekają na to jak trudno się pracuje z kodem tam.
- Rejestracja:prawie 4 lata
- Ostatnio:3 minuty
- Postów:219
0
Mnie się podoba, jeśli chcesz zacząć modularnym monolitem, co jest "obecnym trendem", a potem rozbić to na mikroserwisy z czystą architekturą.
Możesz też pozbyć się tych wewnętrznych paczek (folderów) i trzymać czysto podział na domeny, przy założeniu, że będzie tam max kilka klas
To może być pomocne
edytowany 1x, ostatnio: Productionserver
jeśli chcesz zacząć modularnym monolitem, co jest "obecnym trendem" Kurde to znowu się coś zmieniło? Co 2 lata to nowy trend... Ja już je olewam i robie jak mi wygodnie... :)
spokojnie, za 10 lat znów wrócą mikro/makroserwisy pod nową nazwą
To mikroserwisy gdzieś odeszły, że maja wracać?
Bo na konferencjach są 2 ścieżki: dla tych, którzy podjęli dobrą decyzję o mikroserwisach, i dla tych, którzy tego żałują. Dla tych drugich są prezentacje o monolitach. I wszyscy zadowoleni xD
@somekind: nie odeszły, po prostu ludzie pchają je wszędzie bez potrzeby, stąd idea "zacznij od modularnego monolitu"