Chodzi o to. Tworzę sobie klasę UserDAO(@Repository), która tam sobie dziedziczy z jakiegoś CRUDowego repozytorium Spring Data. Następnie tworzę interfejs UserService i klasę implementującą ten interfejs UserServiceImpl(oznaczoną "@Service", stworzony bean) i w tej klasy wstrzykuję zależność dla UserDAO, dzięki czemu mam stworzą logikę biznesową do obsługi bazy - UserDAO. Czyli mam stworzoną klasę "Service", którą mogę wstrzyknąć jako zależność gdzieś w kontrolerze. OK. Czyli mam już ten serwis. Teraz np. chciałbym sobie stworzyć klasę, która odpowiada za walidację danych podanych przez użytkownika podczas rejestracji, albo np. klasę, która wysyła wiadomości na pocztę elektroniczną. I tu jest moje pytanie. Czy z wszystkich takich klas również tworzyć bean'y i wstrzykiwać po prostu zależność czy bawić się w tworzenie nowe obiektu(np. new SendMessageService). Obecnie w moim programie mam klasy np. RandomNumberService, SendMessageService, ValidatorService, EncodeService. Wszystkie te klasy są bean'ami, przez co nie tworzę ciągle ich obiektów, tylko wszędzie w kontrolerze są na górze oadnotowane @Autowired.
Wbrew temu co ktoś tu później może napisać: nie ma prostej odpowiedzi. Bo to jest wojna idei -> SOA vs. DDD. Podejście które opisałeś to takie full-SOA, gdzie wszystko teoretycznie jest potencjalnych serwisem który można eksternalizować. To powoduje oczywiście że nagle cały kod robi się proceduralny (albo funkcyjny!). Niemniej generalnie to się trochę nie sprawdzi dla większego projektu, bo mimo wszystko będziesz gdzieśtam miał obiekty które nijak nie są bezstanowe i robienie z nich beanów byłoby dziwnym pomysłem. W praktyce w takiej sytuacji robi się takie SOA-like podejście do interakcji z zewnętrznymi serwisami a poniżej tego robi się coś przypominającego bardziej "klasyczne OOP" / DDD.
Dla twojego przykładu z wusułaniem wiadomości -> co z klasą Message? Ona beanem nijak nie będzie, ją ewidentnie trzeba stworzyć samemu. I co jeśli chciałbyś móc ją enkodować/dekodować w różnych miejscach w kodzie? Będziesz tam wszędzie wstrzykiwał sobie odpowiednie serwisy? A co jeśli Message jest częścią większego obiektu (który też nie jest beanem)? Dużo wygodniej byłoby właśnie w klasie Message mieć metodę encode(). Zauważ jednak, że to wcale nie wyklucza całkiem twojego EncodeService, bo równie dobrze może on być zależnością Message wstrzykiwaną "ręcznie" w trakcie tworzenia tego obiektu. To szczególnie sensowne jeśli są inne obiekty korzystające z tej samej logiki.
edit: poczytaj sobie https://4programmers.net/Forum/Inzynieria_oprogramowania/276798-wstrzykiwanie_zaleznosci_a_testy_jednostkowe_ ;)