@fes0r тогда тайпхинтинга не будет, и от массива не сильно отличаться будет)

Anton именно по этому я юзаю массивчики

слишком жесткий оффтоп

?

Сорян

Anton повторюсь. Предствь что у тебя за DTO отвечает сущность. И тебе запрещено редактировать этот код (буквально, сущность нельзя редактировать)

Anton и тебе надо добавить еще один вариант отображения данных а для этого в твоем DTO не хватает данных

и тебе надо уже новое но сделать его ты не можешь

@fes0r ну кагбе завести пару лишних классов на каждую сущность/аггрегат, зато по царски - сразу увидишь, что в дто нужно новое поле добавить, или поменять формат

почему не можешь?)

Anton но тогда ж никакого разделения

руки связали?

Anton да, связали. Просто запрещено менять код.

SRP и все дела связали тебе руки

ну в ентити добавляешь новый метод, который отдает новое дто

Anton ты только что нарушил SRP, ты поправил класс сущности (бизнес объект) потому что тебе надо что-то по другому сделать на UI

теперь класс сущности имеет две разные (абсолютно) причины для внесения изменений

нарушен принцип единой ответственности

в аду для таких есть отдельный котел

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

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

это и есть твой ui

ну его может просить и другой апи, например)

без разницы кто его просит)

Anton ты серьезно не понимаешь что такое SRP?

https://www.youtube.com/watch?v=yIf3EQmHmyw

пожалуй самое простое и наглядное объяснение из всех что я видел

там же описываются причины почему это может быть полезным

вечером видос гляну

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

но нормально вынести я не понимаю как

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

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

ну CQRS решает таки проблему

ну CQRS для такого случая - это как с авианосца по воробьям)

ну и плюс моего подхода в том, что есть контракт, ну и ошибку я увижу до коммита, например

Anton вот кроме CQRS гарантированного решения проблемы как бы нет.

ну во всяком случае в PHP

friend классы частично решили бы проблему целой минимальной связанности

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

и она довольно усложняет все

Anton ну как... и да и нет. Все отличие будет в устранении автоинкрементов и подобной чуши

Anton а ReadModel можно и так и так вкрутить

хм, тогда может и имеет смсл копнуть глубже

ну как, это оверхэд на самом деле

но не так что надо закладывать изначально

не, тогда нет) само приложение и так дичайше сложное для меня

вот в сложных приложениях думать на тему CQRS имеет смысл)

чтоб оно стало еще сложнее?))

CQRS понижает сложность

разделение операций записи и чтения

p.s. причем обработка команд не обязательно должна быть void

ну мол... в очень большом упрощении это всего лишь значит что ты пишешь в одну фигню а читаешь из другой. Например пишешь в ORM а читаешь из Gateway какого или DQL/SQL

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

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

вот это я называю "посторонней фигней"

я пока в CQRS вообще не вдавался - не совсем понимаю всю идею

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

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

или делать event sourcing как крайность

когда тебе пипец важно не проебать вообще никаких данных

пишешь ивенты читаешь данные

ну мол... в очень большом упрощении это всего лишь значит что ты пишешь в одну фигню а читаешь из другой. Например пишешь в ORM а читаешь из Gateway какого или DQL/SQL

ну, скорее, пишешь ты в Domain Model у которой только бизнес-методы, а читаешь из готовых дтошек

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

если мы про event sourcing

ERROR: S client not available

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

> ивенты ж из сущности по итогу вытянуть надо) retriave не геттер

он меняет стэйт

это как array_pop

хотя, ивенты может и вообще не стейт модели

ну, ты в самом аггрегате никогда к списку ивентов не обращаешься же

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

ну тип того

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

а кто пинает и кого пинать деталь реализации

там даже active record может быть))

recordThat(Event $event) { $event->save(); $this->notifyThat($event); }

ну или как-то более красиво, не вмешивая ar в наши ивенты, но суть в общем-то не меняется

$dao = new EventDAO($event); $dao->save();

класс юзера на 700 строк(

https://habrahabr.ru/post/314114/ прикольно конечно

кто нибудь юзал blackfire в докере?

мне тут cli скриптик надо отпрофилировать и я туплю

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

что бы глянуть че почем

? запусти без докера

не выйдет

а в доках смарел?

окружение надо

https://blackfire.io/docs/integrations/docker

смотрел, там про http

а разница?

cli не хочет почему-то так дебажиться

сча еще гляну может с конфигами намудрил

а все, понял

401-ая ошибка