SP
короч, это все про то что бы выстраивать явные потоки данных внутри твоего приложения. Если ты передаешь DTO куда-то и потом разбираешься что с ней делать (дифы всякие и прочее) - то это потом будет тяжело сопровождать.
Size: a a a
2021 April 01
SP
https://www.destroyallsoftware.com/talks/boundaries - вот тут неплохо рассказывается базовые вещи относительно того как структурировать приложение. Всякие эти идеи functional core imperative shell и вот это все. Как это все с тестированием связано и с сопровождением
SP
ну обьект это же инстанс класса
объекты и классы в ООП вторичны. Важно как они общаются между собой, что позволяют друг другу
SP
и да - объекты это процессы а не "сущности". Сущности абсолютно бесполезная штука которая является наследником времен когда все системы были однопользовательские
CB
фабрики, которые берут на себя начало жизненного цикла для сущностей или DTO, пересмотр что есть валидация данных а что инварианты (например тот факт что у тебя email должен быть валиден - валидация ДО сохранения тут бесполезна - тут надо ловить фэйлы констрейнтов в базе уже после сохранения).
Есть такое достаточно простое правило - конструкторам не желательно кидать исключения. Потому тебе нужны фабрики и билдеры. Причем другие сущности вполне могут быть этими фабриками или билдерами. Не надо зацикливаться что фабрика это "сервис с суфиксом
Есть такое достаточно простое правило - конструкторам не желательно кидать исключения. Потому тебе нужны фабрики и билдеры. Причем другие сущности вполне могут быть этими фабриками или билдерами. Не надо зацикливаться что фабрика это "сервис с суфиксом
Factory"твои ответы заставляют много думать, благодарю)
v
пасоны, а че за тема с сервислокатором ? рилли DI уберают из симфони?
SZ
SZ
пранк вышел из под контроля?
ДК
пранк вышел из под контроля?
просто из всей пачки это самая адекватная шутка )
v
так это на 1 апреля было что ли?😃
A
v
блин, перечитал еще раз. похоже так😂😂
а кроме этого ничего не стал даже читать
а кроме этого ничего не стал даже читать
SZ
SZ
эт поярче
BB
DT
что бы флоу данных более явный был, что бы меньше сайд эффектов.
Есть много кейсов когда "что валидно а что нет" решает юзкейс по которому ты что-то создаешь. Перетаскивание этой логики в сущность обычно делает все существенно сложнее.
Сущность должна тебе гарантировать что дернув ее метод (а конструктор это ДО этого) изменения стэйта будут консистентны, но за начало жизненного цикла может отвечать кто-то другой
Есть много кейсов когда "что валидно а что нет" решает юзкейс по которому ты что-то создаешь. Перетаскивание этой логики в сущность обычно делает все существенно сложнее.
Сущность должна тебе гарантировать что дернув ее метод (а конструктор это ДО этого) изменения стэйта будут консистентны, но за начало жизненного цикла может отвечать кто-то другой
Тоесть defensive принцип который говорит что сущность не может существовать в невалидном состоянии идет нафиг?
SP
Тоесть defensive принцип который говорит что сущность не может существовать в невалидном состоянии идет нафиг?
Почему же? Нет, просто конструктор это такая штука что объекта у тебя как такового ещё и нет