Nazewnictwo dla klas usługowych.

markone_dev napisał(a):

A gdzie napisałem, że wymaga? Napisałem że klasy typu ApplicationService, DomainService czy CommandHandler mają swoje odpowiedniki w stylach architektonicznych jak DDD, CQRS czy Onion i ogólnie przyjęło się, że klasy nazywamy w ten sposób czyli OrderService, PlaceOrderHandler, FindUserOrdersHandler, itd.

No właśnie nie jestem pewien. Bo taki Service może być właściwie w dowolnej warstwie i robić cokolwiek, Handler ma już węższy zakres zastosowań, ale takie klasy też można znajdować w wielu warstwach.
Wydaje mi się, że żadne z tych nie nadaje się na konwencje, dla mnie konwencja to raczej coś jednoznacznego i precyzyjnego.

Riddle napisał(a):

markone_dev napisał(a):

Mówiłem o przyjętej konwencji nazewniczej na przykładzie nazw kontrolerów architekturze MVC.

Ale ta konwencja nie przynosi nic dobrego. Tylko zachęca jeszcze bardziej do dopasowania swojego projektu pod framework.

Absolutnie.. Popatrzmy na typową architekturę heksagonalną/onion czy clean jak kto woli:

W tak zaprojektowanym systemie, aplikacja MVC jest tylko szczegółem implementacyjnym warstwy transportowej (adapterem). Może być nawet wygenerowana z szablonu. Nie ma to żadnego znaczenia. W każdej chwili mogę ją zastąpić dowolną inną aplikacją.

Riddle napisał(a):

Jeśli chcesz się dopasować pod framework, i pisać wszystko przez pryzmat tego frameworka (np Spring, Rails, Laravel), to nazywaj klasy tak jak dokumentacja tego frameworka mówi: dodaj Controller, widok, model ORM'owy etc. (tylko nie ubieraj tego w jakieś wzniosłe terminy jak architektura czy MVC).

Znowu bierzesz domysły z powietrza bo o niczym takim nie pisałem.

Riddle napisał(a):

Natomiast jeśli chcesz po prostu stworzyć aplikację, a framework trzymać "at-arms-length", czyli innymi słowy mieć loose-coupling z tym frameworkiem, to warto nie stosować tych konwencji.

Jak najbardziej można stosować te konwencje i mieć loose coupling z frameworkiem. Zobacz jeszcze raz na diagram powyżej.

Riddle napisał(a):

ja mówię o tym, że czysto zrobiona aplikacja w ogóle nie powinna mieć struktury takiej jaka wychodzi jak odpalisz scaffold frameworka.

Kolejne insynuacje i filozofowanie na temat którego nie poruszałem bo nigdzie nie pisałem o tworzeniu aplikacji z szablonu (sic).

Riddle napisał(a):

w takiej aplikacji nie ma sensu dodawać zarostków Service, Handler, etc, bo wszystko jest pogrupowane po odpowiedzialnościach

A ja uważam że jest sens bo dodając service do nazwy klasy wskazujemy jasno na przeznaczenie tej klasy. Tak samo jak builder czy factory w nazwie klasy wskazuje osobom znającym wzorce projektowe jej przeznaczenie, tak samo widząc service w nazwie klasy zwłaszcza gdy mamy architekturę Onion/Clean/Hexagonal to można się domyślić, że będziemy mieli tam do czynienia z implementacją logiki aplikacyjnej czyli konkretnych przypadków użycia czy tam procesów biznesowych (domain service). Tak samo z CQRS. Gdy w warstwie aplikacji mam nazwy typu FindUserOrders FindUserOrdersHandler to wiem, że ktoś stosuje podejście CQRS.

@markone_dev zgadzam się prawie ze wszystkim, oprócz dwóch rzeczy:

markone_dev napisał(a):

A ja uważam że jest sens bo dodając service do nazwy klasy wskazujemy jasno na przeznaczenie tej klasy. Tak samo jak builder czy factory w nazwie klasy wskazuje osobom znającym wzorce projektowe jej przeznaczenie, tak samo widząc service w nazwie klasy zwłaszcza gdy mamy architekturę Onion/Clean/Hexagonal to można się domyślić, że będziemy mieli tam do czynienia z implementacją logiki aplikacyjnej czyli konkretnych przypadków użycia czy tam procesów biznesowych (domain service).

Rozumiem zamysł - chcesz nazwać klasę w taki sposób, żeby było wiadomo dokładnie co robi. I tutaj pełna zgoda - na tym samym mi zależy.

I zgadzam się że jak zaczynasz tworzyć aplikacje, to dodawanie takich zarostków może pomóc się orientować w aplikacji co czym jest. To jest nawet niezły pierwszy krok. Ale stąd trzeba iść dalej - bo są lepsze sposoby nazywania klas, i moim zdaniem nie należy zostać w tym miejscu, tylko właśnie nazywać je lepiej.

Nie powiem ze te zarostki Service i Handler są całkiem źle, bo faktycznie są trochę lepsze niż całkowicie złe nazwy. Ale nie powiem też są są dobre, bo da się nazywać te klasy dużo lepiej.

Problem z takim pomysłem jest to, że jak masz dużą aplikacje, to z tego wychodzi ze masz np 100 service'ów, 100 handler'ów, 100 factory, 100 repozytoriów, etc. i to jest słabe.

markone_dev napisał(a):

A ja uważam że jest sens bo dodając service do nazwy klasy wskazujemy jasno na przeznaczenie tej klasy. Tak samo jak builder czy factory w nazwie klasy wskazuje osobom znającym wzorce projektowe jej przeznaczenie, tak samo widząc service w nazwie klasy zwłaszcza gdy mamy architekturę Onion/Clean/Hexagonal to można się domyślić, że będziemy mieli tam do czynienia z implementacją logiki aplikacyjnej czyli konkretnych przypadków użycia czy tam procesów biznesowych (domain service).

Skoro implementujemy jakiś przypadek użycia, to czemu zatem nie nazwać tej klasy UseCase?
Będzie miało dużo więcej sensu niż Handler czy Service, które są okropnie generyczne, i nie mówią nic.