@oleynikgleb
Вот статья на его блоге по поводу всего этого ) Может и только ее достаточно будет
https://enterprisecraftsmanship.com/posts/domain-vs-application-services/
Я просто уточню ещё, это в сторону слоев архитектуры? или к этому оно не привязывается?
Gleb
Павел
Я просто уточню ещё, это в сторону слоев архитектуры? или к этому оно не привязывается?
Ну отчасти, наверное, да.
В слоистой архитеткуре же есть слои юзкейсов и домена. Вот юзкейсы - аппликейшен сервис, а домен - доменные сервисы)
Павел
Т.е. в слое домена не только сущности. И вот как раз это о том, что бы вычленять бизнесовую логику.
Gleb
Ага, но у нас же все равно получается что БЛ зависит от сущностей. Или мы уходим от зависимостей на другие сервисы?
Павел
Ага, но у нас же все равно получается что БЛ зависит от сущностей. Или мы уходим от зависимостей на другие сервисы?
БЛ должна быть в сущностях, и в Доменных сервисах в идеале
Павел
Постучаться в репозиторий - это не БЛ
Павел
Достатать сущность - это не БЛ
Павел
Даже сохранить сущность - это не БЛ
Gleb
БЛ должна быть в сущностях, и в Доменных сервисах в идеале
Так, а вот можно ещё немного подробнее про БЛ в сущностях. Я сущности воспринимаю как структуру данных с набором getter/setter. И сходу не могу придумать какую БЛ туда можно поместить.
Либо я опять путаюсь в терминах.
Павел
Так, а вот можно ещё немного подробнее про БЛ в сущностях. Я сущности воспринимаю как структуру данных с набором getter/setter. И сходу не могу придумать какую БЛ туда можно поместить.
Либо я опять путаюсь в терминах.
Это анемичная сущость, есть рич сущности где логика в них
Gleb
БЛ - это не про сохранить, достать. А про то, на каких условиях сохранить/достать получается.
Nikolay
Gleb
Это анемичная сущость, есть рич сущности где логика в них
О сколько нам открытий чудных... пойду читать.))) А вообще тянет обратно в Битрикс... там так всё просто. 😂😂😂 Шучу конечно, не тянет обратно.)
Павел
БЛ - это не про сохранить, достать. А про то, на каких условиях сохранить/достать получается.
Вот в вашем коде было что то про количество, какие то условия в приватном методе - это и есть БЛ
Gleb
Вот в вашем коде было что то про количество, какие то условия в приватном методе - это и есть БЛ
Да, видимо разница в терминологии.
В моем понимании мы читаем/пишем данные. В БЛ без разницы откуда и куда. В этом сервисе мы определяем условия, по которым мы данные куда-то потом записываем - в бд, выводим графиком, прочее - уже без разницы.
Павел
@oleynikgleb вот еще можете посмотреть https://ocramius.github.io/doctrine-best-practices/
Павел
Да, видимо разница в терминологии.
В моем понимании мы читаем/пишем данные. В БЛ без разницы откуда и куда. В этом сервисе мы определяем условия, по которым мы данные куда-то потом записываем - в бд, выводим графиком, прочее - уже без разницы.
БЛ вообще не про запись/чтение. Это чисто условия и алгоритмы бизнеса. Врядли алгоритмы бизнеса - график, куда сохранять и т.д.
Павел
В случае кредита - это условия выдачи кредита и построение процентов. Откуда они прилетели и куда улетят - пофиг.
Павел
Не, ну если ваше приложение продает графики и это бизнесовая логика - то да.
Gleb
Да, я так и понимаю, просто некорректно выразил свою мысль и не уточнил, что получение/запись данных это не к БЛ.
Юра
@oleynikgleb вот еще можете посмотреть https://ocramius.github.io/doctrine-best-practices/
Avoid composite primary keys. Мда. Крутые советы конечно
Юра
Но есть и дельные не спорю
Павел
Avoid composite primary keys. Мда. Крутые советы конечно
Ниже в этом слайде есть пояснение, что есть ли на это причины. Опять таки избегайте, а не "не используйте".
Возможно композитная сущность - является самостоятельной и самодостаточной в домене.
Павел
Ну а вообще любой совет - это совет, и надо пропускать через здравый смысл и свой домен
Юра
Свой валидатор )
Юра
Мне кажется вот честно, что если прочитать всех советчиков и авторов умных книг, то просто страшно вообще код писать
Юра
По-любому нарушишь десять паттернов и все возможные инварианты
Павел
Мне кажется вот честно, что если прочитать всех советчиков и авторов умных книг, то просто страшно вообще код писать
Надо брать избирательно под свои нужды, а не тупо следовать
Павел
Та же анемика неплоха, где нет логики
Юра
Да так и есть. Знать не значит все использовать
Юра
Вообще любое решение обычно имеет не только плюсы но и минусы автоматически. Все надо взвешивать
Павел
чет щелкал туда сюда
Юра
ОРМ просто странная концепция. Вроде и доменя но без логики. И вроде как сами по себе модели не зависят от бд, т.е. это и не инфраструктура.
Юра
Какой вот это слой? Я про энтити
Юра
Или орм это и есть просто о дельный слой?
Юра
Слой орм
Юра
Почему нет )
Павел
Если вы там не делаете БЛ - это лишь ваши личные предпочтения
Юра
Да тут был холивар давно где говорили про анемик модели и логику выносить из энтити
Павел
Да тут был холивар давно где говорили про анемик модели и логику выносить из энтити
Ну какой то холивар ен в ту сторону
Юра
Это не мои предпочтения
Павел
Обычно топят ровно наоборот, даже в этом докладе
Юра
Это как раз большинство чата тогда топило за анэмик модели
Юра
Ну типо
Юра
Энтити это не сервис
Юра
Как она получит сервис
Юра
Сразу в метод передавать можо конечно
Юра
И потом понеслось что если логика требует сервис то это одно, а не требует то это другое
Юра
Короче болото черт ногу сломит
Павел
Можно передавать в энтити сервис, правда желательно чтобы он сам был без зависимостей.
Можно оставить логику в сервисе и тащить данные из энтити.
Но в том,и в том случае энтити в слое домена
Юра
Слой домена я так понимаю содержит не только логику
Павел
Как можно вообще говорить о ДДД и анемике, если сам ДДД подразумевает рич
Юра
Та хз не спрашивай
Юра
Ч отказываюсь в это вступать
Павел
))))
Павел
Ну если говорить о риче плюсы:
- Истинная инкапсуляция
- Жесктость модели и сохранение инвариантов.
Минусы:
- надо уметь дробить, чтобы сущность не выросла до миллиона строк) Но даже когда разрастается, это все еще можно контролировать, просто неудобно.
Анимик плюсы:
- не надо задумываться что как дробить, так как все в сервисах, можно вытащить кусками из разных энтити что надо и провернуть операцию в сервисе
Минусы:
- отсутствие инкапсуляции и отсуствие жесткости к сохранению инвариантов. Любой Петя может дернуть сущность и выполнить setProperty с любым значением.
Юра
Типо запретить дергать методы
Юра
Но такое да
Vlad
типы свои городить?)
Юра
Поймет откуда дерг идёт
Юра
И если не из сервиса то по рукам
Dmitriy
костыль какой то
Павел
И если не из сервиса то по рукам
НУ а если из сервиса? Но все равно это невалидный "дерг". Для валидности надо было например предварительно через другой сервис еще прогнать и чекер
Dmitriy
еще и линтер писать только чтобы не думать и тупо анемию сделать
Юра
Решается вообще френд классами
Юра
Но их нет )
Павел
Решается через setProperty($value, Checker $checker) , все проще)
Юра
Да можно в сеттере делать дамп стактрейс вообще
Юра
И смотреть откуда
Юра
Но это всеравно не решает вопрос инкапсуляции
Юра
Всеравно можно дернуть сеттер напрямую
Юра
А проверять инварианты в каждом сеттере?