Вопрос изначально был в том что спринг на своём сайте предлагают другую структуру

solid не обязательно про классы и ооп. solid это просто набор принципов, они применимы и к фп например также

😊

Ну тогда можно и сделать как они советуют. Я думал вопрос был про практичскую ценность разбивки на модули

Как опрос показал не нужно делать так как они советуют

То есть на твой выбор

Но никто так не делает

Принцип разделения по сущностям используется например в Андроиде, это очень удобно

Там чаще всего связность низкая

В спринге же сущности протекают ни в один сервис

Я вообще одно время практиковал доменные сервисы, т.е. за контроллерами два слоя сервисов, за которыми уже слой базы данных. Первый слой это бизнес слой, второй доменный. В доменом слое происходят операции специфичные для конкретных сущностей, в бизнес слое - какие то интеграционные операции, которые связывают между собой доменные. В каких то случаях это можно успешно выразить через один сервисный слой и богатые сущности, которые сами знают что с ними можно делать, но это получения далеко не всегда

Ещё одна разница доменного и бизнес сервиса - первый всегда отдает сущности, второй всегда отдает дто

Но есть одно но, когда пишешь голые круды и там все операции затрагивают одну сущность - доменные сервисы выражаются, просто нет в них смысла

Всем привет
Кто может подсказать.
Я использую вот эти API для получении информации и пользователи Google по oAuth2
https://www.googleapis.com/oauth2/v2/userinfo
https://www.googleapis.com/userinfo/v2/me
В ответ приходят только 4 поля:
 "id": "",
 "email": "",
 "verified_email": true,
 "picture": ""
 
Во всех описаниях там должно быть 11 полей (https://any-api.com/googleapis_com/oauth2/docs/userinfo/oauth2_userinfo_get)

В тестовых аккаунтах имя фамилия и пол заполнены, но они почему то не приходят, в чем может быть причина?

потыкай параметр fields, в доке он описан

Я и сейчас так делаю. Почему перестали и что стали использовать вместо этого?

Просто эта идея с 2-мя слоями "сервисов" зарождается сама собой, когда оказывается, что тебе нужно производить какую-то доменную операцию в конечном счете из разных контроллеров. А т.к. 1-й уровень сервиса работает с ДТО, то во-первых инжектить их друг в друга - сразу начинает попахивать (и чревато круговыми зависимостями). Во-вторых, даже если это сделать, ты получишь ДТО, а тебе нужен домен. В итоге 2 слоя "сервисов" получаются сами собой. Просто иначе сложно переиспользовать код. Только я бы 2-й слой не стал называть слоем "сервисов".

Я бы и первый слой, честно говоря, не стал. Но так уж сложилось почему-то.. Мы сами себя ограничиваем, и вместо множества разных классов делаем какой-то UserService и пытаемся туда притянуть за уши все операции с сущностью User. Хотя по сути UserService - это часть контроллера, если так разобраться. И его методы обычно маппятся 1-к-1 на методы контроллера, принимают и возвращают DTO и т.д. А все бизнес-операции должны быть где-то в нижележащих слоях в более специализированных классах без суффикса Service (и вообще без какого-либо суффикса, хотя чаще всего какой-то приходится придумывать, типа UserManager. Мне это не нравится, но не понятно, как по-другому.).

я так и выделал сущности Service и DomainService

ушел не я, пара проектов, в которых я не сначала и где все уже заведено и отрефакторить все почти как написать заново

но я как минимум внедряю просто сервисный слой, т.к. уже насмотрелся на ахтунг джунов, мало того что в репозитории лазиют из контроллеров, без транзакции частенько, так еще микросервис в итоге сам себя через feign клиент начинает вызывать

ну а как им по другому то еще?) контроллеры друг в друга инжектить)
я уже за говоу хватаюсь - там еще пару джунов набрали)

я уже молчу что я полторы недели потратил н выпиливание из системы повсеместного использования localdateltime с соответствующими миграциями в базе, десяток микросервисов

Бросай кодинг, берись за стандарты и КМБ для джунов)

Кстати, вопрос от Джуна к аудитории. Какой шаблонизатор для бута лучше использовать в наши дни? По работе то используется покрытый мхом jsp