я о том, что у тебя есть бизнес логика, она вызывается где-то и сама логика еще требует вызов чего-то (библиотеки, стореджи всякие, другая часть логики и так далее). если не контролировать все это и пустить на самотек, получится система в которой каждый вызывает все подряд

как пример, я хочу иметь возможность вызывать бизнес логику только из экшенов + я хочу иметь возможность вызывать модели только из определенного слоя моего приложения (условно из сервисов). как мне это лучше сделать и как сделать так, что бы это соблюдалось на уровне всег проекта

на уровне слоев + на уровне логического разделения предметной области (не мешать ордера с постами в блоге и так далее)

А, идею понял. Звучит резонно

а, еще момент, я когда обзор кода делал (https://gist.github.com/davydovanton/a8f3cab112e43cfafbcbbfae2472f6c7) заметил странную особенность, часто в сервисы вытаскивают не часть бизнес флоу, а кусок имплементации, причем довольно часто эта имплементация связанна с базой

там прямо в тексте пример будет о чем я говрю

такое разделение приводит к похожему коду:
https://github.com/discourse/discourse/blob/master/app/services/color_scheme_revisor.rb

т.е. это кусок логики который больше подходит либо моделе, либо отдельной библиотеки, относящейся к предметной области.

смотря на такой код не очень понимаешь зачем оно вообще нужно, т.е. код не отвечает на вопрос “зачем”, но отвечает на вопрос “как”

ща прочитаю и сформулирую свои мысли

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

тогда шаги выполнения становятся осмысленее и появляется контекст, который помогает разобраться в проблеме

Запахло идеями DDD

все так

ну, сложно это назвать прямо ДДД

но идеи от эвент сторминга, да

Как-то у нас был класс ServerManager на 500-800 строк, точно не помню. Лежал в папке lib/services, и с ним было сложно работать.
В итоге я его переписал на кучку srp классов вида BootstrapServer, RenameServer, DeleteServer, DeployServer и прочие. Лежали они так же в lib/services, но работать было гораздо удобнее.

Мне кажется, не место влияет, а подход к написанию (это к одному из предыдущих сообщений про app/services)

Такой подход с добавлением глаголов в названия позволял не давать классам разбухать и проще следовать SRP было

посмотрел твой пример, в целом ты говоришь про проблему coupling и cohesion (связанности) абстракций. и второй момент, про слишком "абстрактные" абстракции без осмысления бизнес-логики. я не знаю честно говоря, как первая проблема может решаться на уровне фреймворка, а вот по ддд в принципе, фреймворк мог бы давать рекомендации, но rails все-таки не ddd-шный фреймворк

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

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

Идеалогически — изящое слово😀

ну за любым решением, фреймворком стоить какая-то идеалогия