Д
Или у тебя там html с jQuery?
Size: a a a
2020 December 15
k
Эм... Ну у тебя на фронте есть Стейт какой у компонента формы.. в зависимости от того что там натыкал юзер компонент будет знать что куда отправлять.
я вообще про то, что если поместить 2 формочки на 1 страницу - это не противоречит высказыванию "агрегаты (запись) в системе по больше части совпадает с формочками".
k
или вот кто сталкивался с полотном CRUD, на несколько десятков полей, у которого некоторые поля друг от друга зависят и там сложная валидация какая-то получается.
Вы начинаете навешивать группы валидации для разных ситуаций и т.п. По типу если выбрана галочка, сумма больше такой-то и дата рождения меньше... и прочую весёлую чернь
Мне кажется(я не знаю), что формы подобного рода тоже бьются вместе с агрегатами
Вы начинаете навешивать группы валидации для разных ситуаций и т.п. По типу если выбрана галочка, сумма больше такой-то и дата рождения меньше... и прочую весёлую чернь
Мне кажется(я не знаю), что формы подобного рода тоже бьются вместе с агрегатами
YG
Я слабо понимаю зачем нужны агрегаты, если коллабораций нет. Eventual consistency - код не упрощает, а я бы сказал, что усложняет.
SP
Я слабо понимаю зачем нужны агрегаты, если коллабораций нет. Eventual consistency - код не упрощает, а я бы сказал, что усложняет.
Все так, если коллаборации нет то не надо выдумывать.
SP
Другой вопрос что все эти заявки часто колаборацию подразумевают. Хотя не всегда
k
окей, коллаборация - это точно причина дробить, тут сложно спорить.
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
2020 December 16
DT
окей, коллаборация - это точно причина дробить, тут сложно спорить.
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
по трейтам раскидай и готово
k
по трейтам раскидай и готово
SP
окей, коллаборация - это точно причина дробить, тут сложно спорить.
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
Стоит, конечно. Но тут как бы вопрос скрытой сложности
k
Стоит, конечно. Но тут как бы вопрос скрытой сложности
скрытой сложности? В смысле инфраструктуры под это?
DT
скрытой сложности? В смысле инфраструктуры под это?
как с микросервисами, неправильно порезал - страдаешь)
k
порезал - страдаешь, не порезл тоже страдаешь 🤔
DT
порезал - страдаешь, не порезл тоже страдаешь 🤔
жизнь программиста
k
похоже жизнь - это боль
DT
По мне, в этом очень помогает ЕС, когда ты сначала напроектировал событий, и потом уже можешь по ним резать
DT
Т.е. ЕС тут не очень-то и обязателен, но события не будут являться чем-то сбоку, не получится филонить
DT
А если неправильно порезал, то события легче переносить между партициями, и даже нет проблемы их редактировать. Понятно что так не стоит делать ни в коем случае. Но с оговорками, только если агрегат состоит из событий, и от этих событий не зависит никакая (!!!) внешняя система (сущность или агрегат)
DT
так же как в гите в общем) если ветка ушла на remote, ты не меняешь историю, а пока часть истории на локалке - то редактируй как хочешь, никакой проблемы в этом нет
YG
окей, коллаборация - это точно причина дробить, тут сложно спорить.
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
Но что на счёт сложности? Стоит ли дробить ради снижения сложности?
А как агрегаты снижают сложность? И не повышают ли они ее?