🐴
короче
🐴
исходный вопрос
Sergei
давай
Sergei
(а то я запутался)
🐴
беру и всем моделям говорю: "нельзя вилкой"
🐴
т.е. нельзя сеттеры
Evgeniy
как оно после этого immutble?
сервис immutable так как нет публичных сеттеров меняющих аргументы переданные конструктору
Evgeniy
данные переданные в конструктор не меняем
🐴
как это может повлиять на архитектуру проекта в целом?
Evgeniy
через публичные методы
Sergei
как это может повлиять на архитектуру проекта в целом?
тебе на каждый чих придется создавать новый экземпляр объекта
Evgeniy
т.е. нельзя сеттеры
имхо не лучшая идея но попробуй если время есть)
Evgeniy
лучше 1 раз увидеть чем 100 раз услышать)
Sergei
или следовать CQRS
я пошел по второму кругу перечитывать его, ибо я похоже что-то упустил
Ale
насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self
ValueObject удобно делать immutable, потому что он определяется только своими значениями
Ale
несколько объектов спокойно могут ссылаться на один и тот же vo
Ale
с сущностями сложнее, если они immutable, то ссылки из других сущностей будут не на объекты, а только на id, получать объекты каждый раз для общения надо заново, плюс при изменении надо не забывать их словить и заперсистить
Ale
в cqrs read-model это не доменный объект, а что-то уровня dto + finder к нему
Ale
доменная модель это write model
🐴
Понял
🐴
То есть cqrs это не совсем про мой случай
Ale
а сервисы immutable потому что не имеют состояния... Ну да)
Ale
например UserService
не надо так называть сервисы(
Evgeniy
не надо так называть сервисы(
а как называют в вашей религии ?
Evgeniy
Serivce часть namespace ?)
Evgeniy
Здесь же все ООП, ORM, DDD, SOLID, CORS
Evgeniy
причем наверно каждый по своему понимает эти термины)
fink3L
а кто-то не понимает 😏
Anonymous
Вы продолжайте, мы тут сидим, молчим , гуглим
Evgeniy
Ну тогда mvc, тут довольно много всего можно нагуглить)
invariance
=D
Evgeniy
работать надо(
Anonymous
=D
тру
fink3L
тру
обнимемся
fink3L
но у меня хоть часть того, что вы здесь обсуждаете в проекте, вроде.
Dmitriy
=D
о. у него новая картинка . спс.
Ale
а как называют в вашей религии ?
зачем мне навязывать свою религию, если я могу указать на проблемы твоей :3 Где заканчивается ответственность UserService? Какие методы там должны быть?
Evgeniy
где заканчивается там и заканчивается)
Evgeniy
это все зависит от задачи)
Ale
как ты понимаешь, новый метод надо добавить в UserService или куда-то еще?
Evgeniy
по фазе луны
Evgeniy
это сарказм
Evgeniy
если серьезно то зависит от ситуации и от доступных вариантов в приложение
Evgeniy
просто строить архитектуру которую понимает только 1 человек в команде тоже не есть гуд
Evgeniy
даже если она сделана по всем канонам
Evgeniy
и лучшим практикам
Ale
ну так как новому человеку понять
Ale
чем занимается UserService
Evgeniy
он предоставляет часто выполняемые действия пользователя в виде методов
Evgeniy
чтобы вызвать из контроллера и не парится
Evgeniy
или middleware или еще откуда
Ale
http://eax.me/kolkhoz-doctrine/
invariance
http://eax.me/kolkhoz-doctrine/
интересный бложек, спасибо
Ale
http://eax.me/kolkhoz-doctrine/
норм оттуда коммент: "Технический долг (как и финансовый) это инструмент, который надо грамотно применять."
Ale
почему нет AppService где просто частые действия в приложении живут?
Evgeniy
почему нет AppService где просто частые действия в приложении живут?
потому что в приложение не только пользователи
Evgeniy
и делать god object не везде возможно
Evgeniy
и нужно
Evgeniy
тут опять же все от деталей ситуации зависит
Sergey
> и делать god object не везде возможно ты хочешь сказать что god object это хоть когда-нибудь нужно?)
Evgeniy
когда поджимают сроки например
Ale
потому что в приложение не только пользователи
т.е. методы UserService объединяет то, что они все работают с User?
Ale
когда поджимают сроки например
это отличный способ их завалить окончательно)
Evgeniy
это опять же холиварно и спорно)
Evgeniy
если ты можешь за 10- минут написать god object и решить проблему, а нормальное решение займет неделю другую
Sergey
это опять же холиварно и спорно)
да нифина не спорно. GOd object = high coupling = боль
Evgeniy
напиши god object потом со спокойной душой делай решение
Sergey
> если ты можешь за 10- минут написать god object и решить проблему, а нормальное решение займет неделю другую а еще ты можешь подумать 10 минут лишних и придумать солюшен который займет у тебя 20 минут и не будет god object-ом
Sergey
напиши god object потом со спокойной душой делай решение
ты видимо не понимаешь что есть god object либо.... хз
Ale
чет я тож не знаю реальной ситуации, где простое решение может быть god object
Ale
неявные зависимости, сильный каплинг
Ale
а еще потом мутабельное состояние
Ale
мммм
Sergey
я подозреваю что "когда не хочется ставить контейнер зависимостей"