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

python весь immutable

ну "почти весь"

реакт вон на js тоже на этом базируется под копотом, говорят)

имхо в php лучше оставить ValueObject а вот всякие сервисы вполне не плохо делать без side эффектов

типо имутабельные, на самом деле не делать сэтеров и все передавать аргументами в метод)))

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

это опять же имхо

типо имутабельные, на самом деле не делать сэтеров и все передавать аргументами в метод)))

в конструктор?

например UserService

очвидно должен уметь заводить нового пользователя

по username, password и тд это аргументы метода

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

понял

это мое имхо

не факт что правильное

т.е. получается просто соглашение, не жестко заданные правила

компромис скорей)

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

теперь я не понял

ага я тоже, перестал понимать)

как оно после этого immutble?

короче

исходный вопрос

давай

(а то я запутался)

беру и всем моделям говорю: "нельзя вилкой"

т.е. нельзя сеттеры

как оно после этого immutble?

сервис immutable так как нет публичных сеттеров меняющих аргументы переданные конструктору

данные переданные в конструктор не меняем

как это может повлиять на архитектуру проекта в целом?

через публичные методы

как это может повлиять на архитектуру проекта в целом?

тебе на каждый чих придется создавать новый экземпляр объекта

т.е. нельзя сеттеры

имхо не лучшая идея но попробуй если время есть)

тебе на каждый чих придется создавать новый экземпляр объекта

или следовать CQRS

лучше 1 раз увидеть чем 100 раз услышать)

или следовать CQRS

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

насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self

ValueObject удобно делать immutable, потому что он определяется только своими значениями

несколько объектов спокойно могут ссылаться на один и тот же vo

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

в cqrs read-model это не доменный объект, а что-то уровня dto + finder к нему

доменная модель это write model

Понял

То есть cqrs это не совсем про мой случай

а сервисы immutable потому что не имеют состояния... Ну да)

например UserService

не надо так называть сервисы(

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

не надо везде пихать entity manager (

не надо так называть сервисы(

а как называют в вашей религии ?

Serivce часть namespace ?)

не надо везде пихать entity manager (

это как пример

Здесь же все ООП, ORM, DDD, SOLID, CORS

причем наверно каждый по своему понимает эти термины)

а кто-то не понимает ?

Вы продолжайте, мы тут сидим, молчим , гуглим

Ну тогда mvc, тут довольно много всего можно нагуглить)

работать надо(

тру

тру

обнимемся

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

о. у него новая картинка . спс.

ERROR: S client not available

а как называют в вашей религии ?

зачем мне навязывать свою религию, если я могу указать на проблемы твоей :3 Где заканчивается ответственность UserService? Какие методы там должны быть?

где заканчивается там и заканчивается)

это все зависит от задачи)

как ты понимаешь, новый метод надо добавить в UserService или куда-то еще?

по фазе луны

это сарказм

если серьезно то зависит от ситуации и от доступных вариантов в приложение

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

даже если она сделана по всем канонам

и лучшим практикам

ну так как новому человеку понять

чем занимается UserService

он предоставляет часто выполняемые действия пользователя в виде методов

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

или middleware или еще откуда

http://eax.me/kolkhoz-doctrine/

http://eax.me/kolkhoz-doctrine/

интересный бложек, спасибо

http://eax.me/kolkhoz-doctrine/

норм оттуда коммент: "Технический долг (как и финансовый) это инструмент, который надо грамотно применять."

он предоставляет часто выполняемые действия пользователя в виде методов

и что объединяет эти методы в один класс?

почему нет AppService где просто частые действия в приложении живут?

норм оттуда коммент: "Технический долг (как и финансовый) это инструмент, который надо грамотно применять."

хорошая цитата

почему нет AppService где просто частые действия в приложении живут?

потому что в приложение не только пользователи

и делать god object не везде возможно

и нужно

тут опять же все от деталей ситуации зависит

> и делать god object не везде возможно ты хочешь сказать что god object это хоть когда-нибудь нужно?)

когда поджимают сроки например

потому что в приложение не только пользователи

т.е. методы UserService объединяет то, что они все работают с User?

когда поджимают сроки например

это отличный способ их завалить окончательно)