Математическое доказательство ненужности service-layer на бэкенде при взаимодействии через RPC

[Gromilo]

Я из мира .net'а и мне нужен контекст :)

Что за сервисы? Это отдельный класс под каждый метод ендпоинта или что-то ещё? Против чего воюет автор?

Просто меня под каждый метод апи есть отдельный UseCase в домене, который по минимуму зависит от деталей реализации протокола. Контроллеры отвечают за всю http часть (или grpс, если надо) и просто дёргают UseCase. Логику в контроллерах писать не гуд, т.к. UseCase могут быть как в 3 строки, так и в 300. И если всё пихнуть в контроллер, получается свалка.

[qeeveex]

UseCase по сути и есть сервис. Все их по разному называют. У кого-то сервисы вообще состоят из usecase.

[SimSonic]

UseCase это хорошая реализация, а сервис с 100 ответственностями — не очень хорошая :)

[Gromilo]

Так и что в итоге? Автор предлагает писать логику в контроллерах и не париться или что?

[qeeveex]

Видимо да)) Я не вчитывался. По быстрому проскользнул. Сейчас на хабре только так контент и читаю, слишком много мусора.

[DenSigma]

Странная логика. Почему и для sCost и для nsCost слагаемы C и DL одинаковы? С чего бы? Обоснуйте. Разные архитектуры, разные паттерны, разные реализации. С_S != С_NS, DL_S != DL_NS.

[ExTalosDx]

я вообще просто написал crud / r controller, который сам всё дефолтное сам делает. И тебе таким образом нужно потратить секунду времени.

А для остальных методов можно потратить 10 секунд и написать пару методов.

Туда входят абстракции для всех нужных слоёв, довольно простые. По сути реализовал Rest repository или как там технология называется.

(но более простую в использовании в разы)