A Вообще почитайте ответ Максима из ссылки выше. Он просто довольно категоричный и безкомпромиссный к сеттерам/геттерам, но в этом плохого нет (в его категоричности), это выбор каждого. Его ответ довольно грамотный, а так же ссылки на репо, где тоже грамотный проект.

Ну я если я правильно понял:
Лучше производить создание сущности через конструктор в репозитории сущности. Руками прописать для каждой сущности свой метод в репозитории.

Я только не понимаю зачем конструктор - не вижу плюсы. Мы не можем выкинуть сеттеры - нам так и так придёться потом редактировать экземпляр.

Сеттеров в статье выше нет потому что используется Rich Domain Model и для обновления сущности будет использоваться ее подход

Да можно и анемик без сеттеров сделать, кто мешает :)

А обновлять как поля сущностей?

Через методы, просто более глобальные и человечные )) $e->edit($p1,$p2,$p3)

Ну хотя гибрид - фигней попахивает)

Так это по сути Rich, а не Anemic тогда)

Не в репозитории, в сервисе (ну или контроллере). Ну т.е там где у вас главный код

Ну p1 p2 p3 мы можем вычислять снаружи, а это анемик.

Тогда уж Value Object )

Ну id то  есть :)

Но его везде не натянешь)

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

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

А вот где однозначно нужна жесткость и поддержка инвариантов - да.

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

Ребята, тут назрел вопрос по автоматизации генерирования документации)

На одном из докладов услышал интересную мысль о автоматическом обновлении доки Apiary из аннотации в рамках CI/CD. Тогда эта мысль не заинтересовала.

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

Если из коробки, вдруг, недоступно, было бы здорово хотя бы  совместить с NelmioApiBundle...


Буду очень благодарен, если поделитесь ссылочками на материалы по теме.

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

я генерила документацию при сборке образа для прода