пока есть вопросы - есть ответы

ну так я не про сеттеры)

А Я ТО БЛЯТЬ В ПРОЦЕДУРАХ В МУСКУЛЕ ВСЕ ХРАНЮ

Modx хранит пхп код в базе

у нас есть twig в базе)

на твиге свой DSL)

Мне нужно бизнес хранить

да где угодно, если это не противоречит законом роботехники, SOLID и другим

Modx хранит пхп код в базе

Ты мне тут не это

Мне нужно бизнес хранить

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

Я очень оставил сужности на 15 строк

Остальное распихал по менеджерам и сервисам

А мне тут говорят что я плохо сделал

зачем?

Так проще управлять ответственностью

А мне тут говорят что я плохо сделал

не плохо - а как многие. Вопрос связанности. Ты ее увеличил

Так проще управлять ответственностью

все твои сущности уже нарушают SRP

и OCP

не плохо - а как многие. Вопрос связанности. Ты ее увеличил

А если в моделях то нет?

А если в моделях то нет?

что такое "модели"?

что такое "модели"?

Сущности

Сорян

Я обмазался AR

Сущности

если у тебя логика только в сервисах или только в моделях - то скорее всего ты будешь проигрывать) То есть очевидно что логика должна быть и там и там.

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

пошла жара

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

бляха... ребяты...

ну посмотрите вы уже видос :D

Так проще управлять ответственностью

ну как сказать, у тебя есть манагер, который чето делает с сущностью. к примеру у тебя есть Issue сущность тебе нужно закрыть этот Issue, проставить дату закрытия, но при этом если есть дочерние Issues, то не давать закрыть если ты это делаешь все через манагер типа IssueManager->close($issue), то ты никак не застрахован от того что из другой части кода тебе просто кто-то сделает Issue->setStatus(Closed) и при этом хрен ложил на все эти кондишены

там вот хорошо об этом

functional code + imperative shell

мне не очевидно) вопрос декомпозиции. У тебя есть VO, коллекции и прочие штуки которые позволяют тебе декомпозировать логику. В целом можешь погуглить на тему "dependency as code smell" и проследить от этой идеи к whole value

да это понятно, что перегибать не стоит, я и не настаивал...

по поводу дзен - https://pikabu.ru/story/chyornyie_tuchi_zakryili_lunu_1914253

hits blunt...

последний раз вкидываю годнота годнотой

https://www.destroyallsoftware.com/talks/boundaries

последний раз вкидываю годнота годнотой

крайний а не последний)

доклад на самом деле неплох

можно подумать с сервисами не получается сущностей с полтосом методов на пару экранов ))) и половина из них сет гет )

окей, последний на сегодняшнее бодрствование)

Во

Сча станет лучше

тебе повезло)

@figushki посмотри видос что скинул @thatside

@figushki посмотри видос что скинул @thatside

Гляну да.

тут скорее ООП vs процедурный код приятнее когда у тебя Issue->close(), а не колбаса из foreach(Issue->related as subIssue){ if... } Issue->setUpdatedAt(...) Issue->setStatus(closed)

у меня сущности и на геттерах/сеттерах, и кошерно рич без сеттеров

так вот большинство сеттеров не используются нормально

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

так это и есть инкапсуляция

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

а что твой IssueManager инкапсулирует? что в твоем понятии инкапсуляция?

whatever suits your needs

когда у тебя есть скажем Issue, с методами типа close, assign, watch, vote, то это выглядит читабельнее и лучше чем setStatus, setUser, setShitDone

ERROR: S client not available

чем это отличается от менеджмента данных в сущностях?

ну вообще да, я хз, как это работает в ларе - я на ней не писал

хотя бы ради такого надо попробовать)

не в ларе, а в AR)

разные менеджеры можно заменить разделенными сущностями

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

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

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

прямо рачище

зависимостей там не может быть. она может зависить и иметь связи только с другими сущностями

максимум зависимостей - это дто/во но не сервисы и прочее

Ёпта. Есть текстовая трансляция?

сервисы то будут

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

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