Witam,
mam pytanie które nurtuje mnie już jakiś czas, ale nie mogę znaleźć klarownej odpowiedzi. Dostałem kiedyś zwrotkę z wysłanego zadania kwalifikacyjnego, że nie powinno się wstrzykiwać serwisów do serwisów. Tj. Serwisu A do Serwisu B w celu wykonania jakieś operacji.
Ale co w przypadku kiedy faktycznie muszę skorzystać z dwóch? Jak powinny się one komunikować żeby było "poprawnie".
0
1
Ogólnie to oczywiście że można. Jakby nie było można, to by w javie nie było konstruktorów :P Stawiam, że chodziło o konkretną sytuację i konkretną Twoją implementację - może źle rozdzieliłeś te serwisy.
1
Wychodząc od podejścia big-picture; to jeśli masz projekt w którym nie ma żadnego kontenera DI, to wszystkie obiekty komunikują się ze sobą w różny sposób - niektóre sposoby są lepsze niż inne (i mówiąc lepsze, mam na myśli czytelniejsze, prostsze w utrzymaniu, łatwiejsze w testowaniu, etc.).
Jakiś czas temu był za to wysyp frameworków, które próbują zrobić coś jak "deklaratywne podejście" do definiowania kontrolerów - tzn. tworzymy klasę, dodajemy adnotację, i framework "automagicznie" woła go z odpowiednim żądaniem. Jakie to ma wady i zalety? Jedną z cech jest to, że nie korzystamy już z systemu klas javy (np konstruktorów, więc nie możemy użyć standardowych podejść, jak np decorator, observable, etc.). Cokolwiek nie chcemy zrobić z takim kontrolerem, musi być w jakiś sposób obsłużone przez framwork (a to znaczy że jego autor musiał przewidzieć swtorzenie czegoś takiego). I to się wydaje "łatwe i pomocne", jak robimy takie proste kontrolery, ale im bardziej chcesz odseparować framework od logiki, tym to jest trudniejsze.
Jedną z takich cech które framework nam zabiera jest coś absolutnie podstawowego, czyli konstruktor. W "zwyczajnej" aplikacji w Javie, jeśli chcielibyśmy skorzystać z jakiejś zależności, wystarczy przekazać ją przez konstruktor i tyle - najprostszy wzorzec projektowy jaki istnieje.
Ta podstawowa cecha klas w springu jest niestety zabrana, na rzecz deklaratywnych kontrolerów którym "wystarczy" dodać adnotację, i obsługa HTTP jest ukryta w springu. Żeby otrzymać z powrotem możliwość dostarczenia zależności do kontrolera (która została IMO zabrana właściwie przez same design frameworka), dodano moim zdaniem hack/workaround, jakim jest kontener wstrzykiwania zależności. Wstrzykiwanie zależności to jest oczywiście bardzo dobry pomysł, jeśli korzystamy z niego np przez konstruktory. Ale kontenery wstrzykiwania zależności (które się chamsko podpięły pod tę przyjętą nazwę dobrej praktyki), robią taki piggy-back ride, dostarczając hack/obejście na feature który był zabrany przez sam design biblioteki, i teraz jest takim "czymś". Zostało to również puszczone do pozostałych części biblioteki, jak do serwisów i repozytoriów.
Niektórzy próbując "walczyć" z tym żeby framework nie był "nad wszystkim", starają się stosować zasadę z SOLID pod nazwą "Dependency Inversion", i starają się trzymać serce swojej logiki w możliwe odseparowanym miejscu od frameworka - a z reguły im bardziej popularny framework, tym trudniejsze to jest (trudniejsze, bo z reguły im bardziej popularny framework, tym więcej "smaczków" się do niego dodaje, które mają być proste w użyciu, ale nie koniecznie proste w utrzymaniu). Jednym ze sposobów na to w springu, jest nadal pisać swoją logikę - jaknajwięcej się jej dwa w "zwykłych" klasach; i jedynie wsadzić do kontrolera absolutne minimum konieczne do działania aplikacji - i jedynym sposobem na to teraz, to jest wstrzyknąć serwis. Ja do tego podchodzę tak, że piszę kod w taki sposób, żeby jaknajmniej mojego kodu cokolwiek wiedziało o springu. Cała logika, ile tylko się da piszę w zwykłych klasach bez żadnego DI. Potem dodaję malutką klasę z adnotacją springową, która korzysta z napisanych już klas, i ją wstrzykuję. Żadna adnotacja springowa nie jest w "moich" klasach.
Kiedy dostałeś informacje o tym że "nie powinno się wstrzykiwać serwisów do serwisów", to może oznaczać dwie rzeczy:
- albo ktoś tylko słyszał regułkę, i ją teraz powtarza bez zrozumienia
- albo starają się osiągnąć dependency inversion w swoich aplikacjach
Astegard napisał(a):
Witam,
mam pytanie które nurtuje mnie już jakiś czas, ale nie mogę znaleźć klarownej odpowiedzi. Dostałem kiedyś zwrotkę z wysłanego zadania kwalifikacyjnego, że nie powinno się wstrzykiwać serwisów do serwisów. Tj. Serwisu A do Serwisu B w celu wykonania jakieś operacji.
Ale co w przypadku kiedy faktycznie muszę skorzystać z dwóch? Jak powinny się one komunikować żeby było "poprawnie".
Błądem tutaj jest takie przekonanie że jak robić scaffold projektu springowego, to Spring jest sercem, a Twoja logia ma się dopasować dookoła frameworka. Dużo lepszym podejściem jest uznanie że to moja aplikacja jest najważniejsza, i to spring jako biblioteka np do HTTP ma się do niej dopasować.
0
Riddle napisał(a):
Błądem tutaj jest takie przekonanie że jak robić scaffold projektu springowego, to Spring jest sercem, a Twoja logia ma się dopasować dookoła frameworka. Dużo lepszym podejściem jest uznanie że to moja aplikacja jest najważniejsza, i to spring jako biblioteka np do HTTP ma się do niej dopasować.
Spring wymusza bardzo duzo rzeczy, to jest caly ekosystem. On jest doslownie sercem aplikacji, bo to on odpowiada za lifecycle beanow itd. Jezeli chcesz tworzyc rozbudowane aplikacje i traktowac springa wylacznie jako libke do http to najlepiej w ogole z niego nie korzystac i wybrac "normalne" libki, ktore nie maja w sobie tego calego nowotworu.
edit: Od razu mowie, ze to nie znaczy, ze mamy wpierdzielac zdupione adnotacje w core logiki i wszystko do tego dostosowywac. Mowie jedynie, ze spring nie to nie jest jakas biblioteka i nie stworzysz apki w taki sposob zeby moc go sobie dowolnie wymienic na cos innego.
0
Seken napisał(a):
Riddle napisał(a):
Błądem tutaj jest takie przekonanie że jak robić scaffold projektu springowego, to Spring jest sercem, a Twoja logia ma się dopasować dookoła frameworka. Dużo lepszym podejściem jest uznanie że to moja aplikacja jest najważniejsza, i to spring jako biblioteka np do HTTP ma się do niej dopasować.
Spring wymusza bardzo duzo rzeczy, to jest caly ekosystem. On jest doslownie sercem aplikacji, bo to on odpowiada za lifecycle beanow itd. Jezeli chcesz tworzyc rozbudowane aplikacje i traktowac springa wylacznie jako libke do http to najlepiej w ogole z niego nie korzystac i wybrac "normalne" libki, ktore nie maja w sobie tego calego nowotworu.
Tylko ze beany to też jest twór Springa.
Jeśli odpowiednio od dzielisz zależności, i wyniesiesz http jako odpowiednią abstrakcje, to nie ma specjalnego znaczenia czy libka do HTTP to spring czy nie, bo można bardzo prosto bez większego problemu je podmienić.
edit: Od razu mowie, ze to nie znaczy, ze mamy wpierdzielac zdupione adnotacje w core logiki i wszystko do tego dostosowywac. Mowie jedynie, ze spring nie to nie jest jakas biblioteka i nie stworzysz apki w taki sposob zeby moc go sobie dowolnie wymienic na cos innego.
No właśnie powinieneś móc tak napisać aplikację.
Nie widzę jakiejś specjalnej wartości we wsadzaniu Springa jako serce apki. Za to widzę ogromną wartość żeby logika biznesową była w sercu, a spring był "out".
0
edit: Od razu mowie, ze to nie znaczy, ze mamy wpierdzielac zdupione adnotacje w core logiki i wszystko do tego dostosowywac. Mowie jedynie, ze spring nie to nie jest jakas biblioteka i nie stworzysz apki w taki sposob zeby moc go sobie dowolnie wymienic na cos innego.
No właśnie powinieneś móc tak napisać aplikację.
Nie widzę jakiejś specjalnej wartości we wsadzaniu Springa jako serce apki. Za to widzę ogromną wartość żeby logika biznesową była w sercu, a spring był "out".
Ja za to nie widze specjalnej wartosci w zaprzeganiu ogromnej kobyly po to zeby sluzyla jedynie za server http skoro istnieje do tego pierdyliard lepszych rozwiazan. W dodatku o wiele lzejszych i prostszych. Mozliwosci sa dwie:
- Nie bedziesz w stanie latwo podmienic springa na inne rzeczy, bo korzystasz z beanow, konfiguracji kafki i masy innych podstawowych rzeczy w springu i bedzie sie to wiazac z przepisaniem masy kodu.
- Przepiszesz bezproblemowo, bo niczego ze springa nie uzywasz ergo korzystasz z ogromnego frameworka po to zeby sluzyl za http server co jest rownie glupie co zawalenie cora zaleznosciami do 3rd party.
Natomiast istnieje zloty srodek polegajacy na tym, ze korzystasz ze wszystkich dobrodziejstw springa, ktore pomagaja Ci zmniejszych ilosc glupiego boilerplate, ogarnac za Ciebie configi, zbindowac niektore rzeczy, posegregowac itd. Jednak mimo tego, ze nie wrzucasz tej springowej abominacji do swojej logiki biznesowej jestes doskonale swiadomy, ze nie przerzucisz sie ze springa na takiego quarkusa w jeden dzien, bo bedzie to syzyfowa praca.
Spring doslownie odwraca te zaleznosc, ze to on steruje Twoja aplikacja. Jezeli sie na to nie godzisz to po co chcesz go uzywac?
0
Seken napisał(a):
edit: Od razu mowie, ze to nie znaczy, ze mamy wpierdzielac zdupione adnotacje w core logiki i wszystko do tego dostosowywac. Mowie jedynie, ze spring nie to nie jest jakas biblioteka i nie stworzysz apki w taki sposob zeby moc go sobie dowolnie wymienic na cos innego.
No właśnie powinieneś móc tak napisać aplikację.
Nie widzę jakiejś specjalnej wartości we wsadzaniu Springa jako serce apki. Za to widzę ogromną wartość żeby logika biznesową była w sercu, a spring był "out".
Nie odpowiadasz na mój argument. Ja powiedziałem że nie ma wartości w robieniu żeby spring był sercem aplikacji. Większy sens, żeby sercem aplikacji była logika biznesowa - a rzeczy dookoła, takie jak HTTP czy message, powinny być dostarczone przez odpowiednie abstrakcje - jakie chcesz. I wtedy implementację możesz wybrać dowolną.
Ja za to nie widze specjalnej wartosci w zaprzeganiu ogromnej kobyly po to zeby sluzyla jedynie za server http skoro istnieje do tego pierdyliard lepszych rozwiazan. W dodatku o wiele lzejszych i prostszych. Mozliwosci sa dwie:
- Nie bedziesz w stanie latwo podmienic springa na inne rzeczy, bo korzystasz z beanow, konfiguracji kafki i masy innych podstawowych rzeczy w springu i bedzie sie to wiazac z przepisaniem masy kodu.
- Przepiszesz bezproblemowo, bo niczego ze springa nie uzywasz ergo korzystasz z ogromnego frameworka po to zeby sluzyl za http server co jest rownie glupie co zawalenie cora zaleznosciami do 3rd party.
No i dochodzimy do sedna, bo umyka Ci trzecia opcja.
Możesz korzystać z opcji 1, czyli tego co dostarcza spring, ale z odpowiednią abstrakcją, tak żeby podmiana tego była bardzo prosta.
To nie jest tak że jeśli chcesz użyć całej biblioteki, to musi być ona trudna do zmiany. Całe Dependency Inversion się do tego odnosi.
Seken napisał(a):
Natomiast istnieje zloty srodek polegajacy na tym, ze korzystasz ze wszystkich dobrodziejstw springa, ktore pomagaja Ci zmniejszych ilosc glupiego boilerplate, ogarnac za Ciebie configi, zbindowac niektore rzeczy, posegregowac itd. Jednak mimo tego, ze nie wrzucasz tej springowej abominacji do swojej logiki biznesowej jestes doskonale swiadomy, ze nie przerzucisz sie ze springa na takiego quarkusa w jeden dzien, bo bedzie to syzyfowa praca.
Nie jest to złoty środek, bo owszem - korzystasz z funkcjonalności dostarczonych przez spring, tak.
Ale jednocześnie przywiązujesz swoją aplikacje do Springa. I to jest problem. Żeby sobie z tym poradzić należy stosować Dependency Inversion.
Spring doslownie odwraca te zaleznosc, ze to on steruje Twoja aplikacja. Jezeli sie na to nie godzisz to po co chcesz go uzywac?
No właśnie po to żeby korzystać ze wszystkich funkcji Springa, ale w taki sposób żeby moja aplikacja nie była przywiązana do niego. Da się to zrobić używając Dependency Inversion.
Aczkolwiek tytułem dygresji - rozumiem Twojej Stanowsko. Jeśli ja nie znałbym DI i nie potrafił odpowiednio oddzielić logiki od innych elementów, to faktycznie miałbyś rację - miałbym dwa wyjścia. Albo silne przywiązanie do Springa, albo ledwo co go używanie. Faktycznie, tutaj masz rację. I nawet można powiedzieć że jeśli ktoś nie zna DI, to to jest złoty środek.
Ale właśnie! Znajomości Dependency Inversion zmienia wszystko zmienia, bo możesz zarówno użyć całej funkcjonalności dostarczanej przez Springa, ale tak żeby się nie przywiązać do niego.
0
Riddle napisał(a):
Seken napisał(a):
edit: Od razu mowie, ze to nie znaczy, ze mamy wpierdzielac zdupione adnotacje w core logiki i wszystko do tego dostosowywac. Mowie jedynie, ze spring nie to nie jest jakas biblioteka i nie stworzysz apki w taki sposob zeby moc go sobie dowolnie wymienic na cos innego.
No właśnie powinieneś móc tak napisać aplikację.
Nie widzę jakiejś specjalnej wartości we wsadzaniu Springa jako serce apki. Za to widzę ogromną wartość żeby logika biznesową była w sercu, a spring był "out".
Nie odpowiadasz na mój argument. Ja powiedziałem że nie ma wartości w robieniu żeby spring był sercem aplikacji. Większy sens, żeby sercem aplikacji była logika biznesowa - a rzeczy dookoła, takie jak HTTP czy message, powinny być dostarczone przez odpowiednie abstrakcje - jakie chcesz. I wtedy implementację możesz wybrać dowolną.
Nie odpowiadam, bo nigdy nie przeczylem temu co mowisz. Oczywistym jest, ze chcemy miec domene w srodku. Problem jest taki, ze korzystajac ze springa wiele rzeczy dzieje sie automagicznie i troche nie wyobrazam sobie pisania powaznej apki, w ktorej nie wykorzystujesz beanow, bedacych swoistym "budulcem". Tak samo korzystajac z kafka streamow jedyne co musisz zrobic to napisac beana z jedna funkcja do przetwarzania danych, dopisac pare linijek w propertiesach i wszystko masz out of the box. Mozesz to sobie konfigurowac wszystko recznie, spedzic 5 krotnie wiecej czasu, tylko pojawia sie jedno bardzo wazne pytanie: w jakim celu? Nawet wykorzystywanie glupiego controller advice nie pozwoli Ci przepiac sie bezproblemowo na inne rozwiazanie, bo korzystasz ze springowego AOP, ktory jest na swoj sposob unikalny. I co zaczniesz robic reczny error handling dla kazdego z kontrolerow powielajac 10 krotnie ten sam kod tylko po to, ze bedziesz mogl latwiej odejsc od springa?
Do czego zmierzam to stwierdzenie, ze brak bezposrednich zaleznosci do libek w corze wcale nie oznacza, ze mozemy sobie wszystko dowolnie przepinac i bedzie to bezproblemowe.
Popularnym przykladem, ktory zilustruje moj tok rozumowania jest baza sql vs nosql:
Czesto ludzie mysla, ze jak w modelach maja POJO to jest git i mozna sie przepiac z takiego postgresa na cassandre lub odwrotnie. W rzeczywistosci okazuje sie, ze o ile takie przepiecie jest mozliwe to sposob w jaki (podswiadomie) zamodelowalismy pewne klasy i ich relacje jest blizsze podejsciu relacyjnemu. Stad takie rozwiazanie moze i bedzie dzialac na cassandrze, ale jest karkolomne i nieoptymalne. Przydalby sie srogi refactor, a przeciez nie mamy zadnych zaleznosci.
Tak samo jest ze springiem, nie spotkalem sie nigdy z sytuacja zeby jakikolwiek duzy projekt zmigrowal sie ze springa do quarkusa i dziesiatek innych pomocniczych libek majacych na celu wypelnienie "pustki". Ja nie twierdze, ze mamy wrzucac springowe komponenty wszedzie, ani ze domena nie ma byc w centrum. Moje zdanie jest takie, ze nawet korzystajac w zdrowy sposob bardzo ciezko jest sie przepiac ze springa na cokolwiek innego (zakladajac, ze mamy juz naprawde rozwiniety projekt). Z drugiej strony nie jestem zadnym javowcem wymiataczem, a temat jaki sie wywiazal wydaje mi sie bardzo ciekawy, wiec chetnie poznalbym zdanie ludzi bardziej doswiadczonych jak np @jarekr000000 czy @wartek01 .
tl;dr Pisanie w springu tak zeby moc w zupelnosci bezproblemowo przepiac sie na inny framework przypomina mi popularna chorobe jaka jest zbieractwo starych gratow "bo a nuz sie jeszcze kiedys przyda".
5
@Seken: jeśli o mnie chodzi to napiszę jeden fakt - przez 14 lat "kariery" nie widziałem nigdy, żeby ktokolwiek przepinał się ze Springa na cokolwiek innego, więc argument "jak to napiszemy w ten sposób to będzie łatwo się zmigrować" ma dla mnie bardzo małą wartość.
Prawdziwy benefit minimalizacji Springa leży gdzie indziej:
- obiekty, które da się stworzyć bez springowej magii jest łatwo testować. Jak masz jakieś wstrzykiwania przez refleksje to zwykłym junitem tego nie ogarniesz, nie wspominając o innych frameworkach.
- do tego korzystanie z automagicznych frameworków prowadzi do pokusy nadużycia - w dużych projektach ZAWSZE znajdzie się człowiek, który spróbuje czegoś głupiego. Jeśli umówicie się na np. wstrzykiwanie przez konstruktor to chociaż część tych głupich pomysłów skreślisz na starcie
Taki offtop: IMO w dyskusji o tym, czy framework lub jakieś podejście jest dobre czy złe nie należy jedynie patrzeć na jego możliwości, ale też na to czy taki przeciętny programista po półgodzinnym szkoleniu nie będzie robił głupot. Z doświadczenia wiem, że dokumentację ludzie czytają na końcu (jeśli w ogóle), i po prostu należy zakładać, że nie będą znali niszowych smaczków.
Edit: co do oryginalnego pytania - to nie widzę nic złego w tym, że ServiceA ma wstrzyknięty ServiceB. Tzn. w prostych aplikacjach CRUDowych pewnie bym tego nie robił, ale w trochę trudniejszych przypadkach takie wydzielanie kodu z ServiceA do HelperX po to tylko, żeby ServiceB nie wołał ServiceA to głupia dogmatyzacja.
0
wartek01 napisał(a):
@Seken: jeśli o mnie chodzi to napiszę jeden fakt - przez 14 lat "kariery" nie widziałem nigdy, żeby ktokolwiek przepinał się ze Springa na cokolwiek innego, więc argument "jak to napiszemy w ten sposób to będzie łatwo się zmigrować" ma dla mnie bardzo małą wartość.
To jest prawda - rzadko dochodzi do decyzji zmiany biblioteki, ale w dużej mierze dlatego, że jeśli nie masz odseparowanej logiki od biblioteki, to jest to po prostu nie możliwe. Jeśli miałbyś dobrą architekturę, która je oddziela ładnie, to byłoby dużo więcej sytuacji w której ktoś podejmuje taką decyzje. Raz pracowałem w komercyjnym projekcie który taki był, i zmieniliśy w pewnym momencie django na flask.
Jednak trzeba pamiętać że zmiana frameworka w taki sposób to już ostateczność. Inne zalety takiego podejścia to zmiana springa na springa - również znane jako update :D Możemy podnieść spokojnie majora nie martwiąc się że zepsuje nam to coś, ponieważ taki spring jest wyabstraktowany, więc liczba miejsc do zmiany jest dużo mniejsza, a szansa że zepsuje nam to logikę, praktycznie zerowa. Dodatkowo, pozwala to zrobić dużo lepsze Separation of Concerns, bo biblioteki bardzo często mieszają odpowiedzialności, a kiedy to oddzielimy to "nie kusi nas" żeby ulec pokusie frameworka na pomieszanie ich.
1
Riddle napisał(a):
To jest prawda - rzadko dochodzi do decyzji zmiany biblioteki, ale w dużej mierze dlatego, że jeśli nie masz odseparowanej logiki od biblioteki, to jest to po prostu nie możliwe. Jeśli miałbyś dobrą architekturę, która je oddziela ładnie, to byłoby dużo więcej sytuacji w której ktoś podejmuje taką decyzje. Raz pracowałem w komercyjnym projekcie który taki był, i zmieniliśy w pewnym momencie django na flask.
Nie mogę się zgodzić. Biblioteki zmienia się bardzo rzadko bo bardzo rzadko jest taka potrzeba. Nawet jeśli masz coś, co łatwo zmienić to i tak dopóki działa to nie ma po co tego robić.
0
Wszystko zależy od architektury:
- Architektura 3-warstwowa - tam faktycznie wstrzykiwanie jednego serwisu do drugiego jest krzywe.
- DDD: Serwis domenowy może być użyty w serwisie aplikacyjnym.
Najczęściej taka sytuacja że wstrzykujesz jeden serwis do drugiego sugeruje że jest jakaś "część wspólna" którą można wyodrębnić do nowego komponentu lub do nowej metody na obiekcie domenowym/modelu.
2
wartek01 napisał(a):
Nie mogę się zgodzić. Biblioteki zmienia się bardzo rzadko bo bardzo rzadko jest taka potrzeba. Nawet jeśli masz coś, co łatwo zmienić to i tak dopóki działa to nie ma po co tego robić.
Bitlioteki zmienia się często - przeważnie na nowsze wersje. Faktycznie dużo rzadziej na coś innego.
Gorzej z frameworkami - tu nawet zmiana wersji potrafi zaboleć. Aczkolwiek spring jest na tyle dobrze robiony, że problemy przy zmianie wersji są obecnie rzadkie. Natomiast przepisywanie się ze Springa na coś innego to raczej fantasy. Da się, ale w typowym projekcie javowym to będzie jak transplantacja głowy. A narzut, aby przygotować projekt pod takie coś raczej nic nie warty.
Jeśli komuś się ciśnie teraz do głowy CDI -> to nie jest to żadna specjalna alternatywa. Po prostu inna implementacja tego samego "frameworku".
Sama JakartaEE to dramat jeszcze większy od springa, a korzystanie z adnotacji CDI czasem powoduje dodatkowe (i niebanalne) problemy ze Springiem. Quarkus jest trochę lepszy, bo przynajmniej część problemów wyjdzie w trakcie buildu, ale nadal to ten sam dziwaczny sposób programowania.
Powód aby jednak minimalizować użycie springa jest specyficzny dla springa (i całego Java/JakartaEE) czyli poleganie na aspektach runtimowych. W efekcie wszędzie tam, gdzie mamy beany springowe działa dodatkowa magia, która:
a) jest dość delikatna i potrafi się rozlecieć przy drobnych refaktoringach w kodzie, (moje ulubione to zamiana public na private)
b) robi z javy jeszcze bardziej "dynamicznie" typowany język (stringly typed)
c) utrudnia testowanie - choć spring ma jednak dużo wsparcia, żeby to ten problem zniwelować
Tak czy siak, IMO jeśli można coś zrobić prosto bez springa, nawet w springowym projekcie to warto - zawsze jedno problematyczne miejsce w kodzie mniej, nieco krótszy stacktrace w razie problemów i lokalnie większa szansa, ze na produkcji kod będzie działał tak jak podczas testów lub debugu.
1
Przy wstrzykiwaniu czegokolwiek, trzeba bardzo uważać.
0
Tj. Serwisu A do Serwisu B w celu wykonania jakieś operacji.
Niestety nie wiem, co reviewer miał na myśli.
Może chodziło mu o jakiś aspekt architektury heksagonalnej albo vertical slices, gdzie można się umówić, że warstwa „serwisów” ma zależności tylko w dół. Tyle, że ja już widziałem tyle definicji „service”, że właściwie nic bym nie zakładał. W zadaniu rekrutacyjnym jedynie musisz dobrze odseparować controller od tego pod spodem. Jeśli w zadaniu nie było podanej architektury aplikacji, to keep it simple, stupid: controller, service, repo.
Jeżeli trafiłeś na maniaka jakiejś architektury, który nie wytłumaczył założeń, to cóż…. rekrutacja to proces gdzie obie strony decydują, czy chcą pracować ze sobą.