Shub
а он сериализует эфшарповские типы очень своеобразно. и пока коммуникации внутри - то пофиг, но это вот надо слать наружу
Shub
как заставить Newtonsoft нормально сериализовать - наука пока не в курсе дела, Влашин про это ничего не писал
Shub
вообще тут конечно проебы на всех уровнях, начиная с моделлинга
Shub
десятикратно эффективный инженер не учел, что пользователь может не пожелать сообщать номер телефона или какие-то другие данные
Shub
метаться поздно, потому что моделька растащена уже по полсотни микросервисов, которые бодро отрапортованы как рабочие и давно засунуты в прод
Крылатый
Кстати.
Ayrat
Ayrat
а он сериализует эфшарповские типы очень своеобразно. и пока коммуникации внутри - то пофиг, но это вот надо слать наружу
Да нормально же, вербозно ДУ, но можно вылечить
Shub
Да нормально же, вербозно ДУ, но можно вылечить
в моей практике такого еще не случалось. все сторонние сериализаторы как правило друг с другом не совместимы и что-нибудь, да ломают. как по мне, то меньшее зло - это собственный кастомный сериализатор для конкретного поля и стараться избегать непереносимых типов
Shub
в принципе, к этому у нас и приходят, медленно и с мучениями
Ayrat
в моей практике такого еще не случалось. все сторонние сериализаторы как правило друг с другом не совместимы и что-нибудь, да ломают. как по мне, то меньшее зло - это собственный кастомный сериализатор для конкретного поля и стараться избегать непереносимых типов
Ньютон софт с Ньютон софтом совместим
Roman
а он сериализует эфшарповские типы очень своеобразно. и пока коммуникации внутри - то пофиг, но это вот надо слать наружу
да ради христа, подключите этот FSharpLu.Json, возьмите оттуда CompactUnionConverter или как его там, и живите как белые люди
Shub
по Влашину, это должно было быть смоделировано типа так
Shub
type Contacts = Complete of { phone: Phone; address: Address}
| AddressOnly { address: Address}
| PhoneOnly { phone: Phone }
Shub
но прикиньте, как это сериализовать потом?
Roman
Зато к вам в команду надо ЕЩЁ собес проходить!т1
о, я как-то в епаме тоже попал на проект, где надо было проходить доп. собес. Погоняли по алгоритмам, внутренностям дотнета — в общем, классика. Прошел, пришел и охуел от говнокода.
Можт это маркер такой? Если есть "внутренний" доп собес, то проект — раковая пизда?
Ilya
по Влашину, это должно было быть смоделировано типа так
А это точно? А что Влашин предлагает делать, когда добавится третий тип контакта?
Roman
type Contacts = Complete of { phone: Phone; address: Address}
| AddressOnly { address: Address}
| PhoneOnly { phone: Phone }
с фшарплу за нехуй делать. И жсон даже человекочитаемый получается, о чудо
Doge
Shub
А почему не два Option поля?
Можно и два option, особенно если с ними ничего делать не надо. А если надо, то придется обрабатывать 4 возможных комбинации.
Shub
А это точно? А что Влашин предлагает делать, когда добавится третий тип контакта?
Влашин предполагает, что твой домен на 100% известен и на 100% защищен от изменений
Ilya
Смело.
Doge
Можно и два option, особенно если с ними ничего делать не надо. А если надо, то придется обрабатывать 4 возможных комбинации.
А, я понял, что имеется в виду.
Крылатый
Влашин предполагает, что твой домен на 100% известен и на 100% защищен от изменений
Ему бы в документооборот...
Крылатый
С госорганами.
Shub
А, я понял, что имеется в виду.
это все довольно спорно, конечно же. у нас в проекте в 90% случаев использование DU - это вытягивание какого-то флага на один уровень выше, ну например с адресами типа ConfirmedUser of { address: Address; name: string} | NonConfirmedUser of {name: string}
Shub
(это где была попытка че-то моделировать)
Shub
и мотивация мол есть статическая гарантия, что ты не передашь пользователя без адреса туда, где ожидается адрес
Ilya
А потом бац, и в address лежит "null".
Shub
что довольно странное объяснение для меня. во-первых, эфшарп не позволяет сматчить аргумент по кейсу как хаскель или эрланг. можно попытаться извернуться с active patterns, но оно тоже не пашет
Shub
то есть я должен вручную матчить каждый кейс. чем это отличается от ручной проверки флажка isConfirmed?
Shub
во-вторых, что делать, когда пофиг на кейс? таких случаев больше примерно на порядок
Shub
и судя по коду людей, которые пытались что-то сделать по этому поводу, так не только я думаю. по ходу, моделлинг на DU увеличивает требуемый код. причем не просто код, который один раз написал и не трогаешь, а в каждом случае нужно писать практически идентичный код
Shub
ну в смысле, добавил DU в доменный тип - и побежал писать простынки по всем слоям, чтоб сериализовать нормально, чтоб десериализовать нормально, чтобы матчи без ворнингов были и т.п.
Hog
Roman
Влашин предполагает, что твой домен на 100% известен и на 100% защищен от изменений
не предполагает он этого
Shub
не предполагает он этого
может и не предполагает, но тема неполных и меняющихся требований у него не раскрыта вообще
Roman
Чем точнее доменные типы соответствуют реальным вещам, тем удобней работать с этим кодом.
Разумеется, тут надо брать в расчет возможности языка и системы типов
Shub
вот этот код выше - он кстати оттуда и растет. 5 лет считалось, что пользователь обязан иметь эти данные и тупо не может без них существовать. а потом коммифорния приняла закон и нам нужно в моделях, проработавших верой и правдой учесть, что пользователь может быть тупым айдишником, вот так банально
Roman
может и не предполагает, но тема неполных и меняющихся требований у него не раскрыта вообще
По-моему, где-то это затрагивалось, но настаивать не стану. Он и так достаточно много тем затронул, и вполне неплохо при том описал
Shub
Чем точнее доменные типы соответствуют реальным вещам, тем удобней работать с этим кодом.
Разумеется, тут надо брать в расчет возможности языка и системы типов
это как раз и предполагает, что твои реальные вещи - стабильны
Shub
может знания о них неполны, но открытые фундаментальные факты остаются неизменными
Roman
это как раз и предполагает, что твои реальные вещи - стабильны
нет. Вот тебе пример из личного опыта на текущем проекте: мы описывали тех. спецификации для парсинга хмл в доменные типы. И 1 или 2 раза неправильно определили требования к домену, но отразили их в коде достоверно
Roman
И исправить это было гораздо легче, пушто код показывал то, как оно сейчас работает
Shub
это говорит о качестве кода, но никак не говорит о количествах изменений, которые вам пришлось сделать
Roman
Потом мы передизайнили типы в то, как оно теперь должно работать, и после фикса компиляции все заработало правильно
Shub
Потом мы передизайнили типы в то, как оно теперь должно работать, и после фикса компиляции все заработало правильно
ну у вас была такая ситуация, когда один ключевой доменный тип взял и исчез?
Roman
Кол-во изменений тут вещь ортогональная
Shub
из реальности, в смысле, не из кода
Roman
пока не было
Shub
а у нас было
Roman
это говорит о качестве кода, но никак не говорит о количествах изменений, которые вам пришлось сделать
дело в том, что как бы код ни был организован (ддд или не ддд), он все равно сегодня работает именно так, как работает, а завтра нам приходит требование это изменить.
Если код читаем и бизнес правила из него легко вывести, то вносить изменения легко. Если домен по коду понять нельзя, то внесение изменений может лишь показаться простым , и то не всегда— в действительности, в таком коде просто трудно даже оценить, правильно ли он делает то, что должен делать
Roman
Ок, поправочка сразу
Roman
Вносить изменения может быть и не легко, но легко оценить правильность результата. Если код не отражает домен — вносить изменения легче не становится, при условии, что нас интересует соответствие доменной логике, а не изменения ради изменений
Shub
дело в том, что как бы код ни был организован (ддд или не ддд), он все равно сегодня работает именно так, как работает, а завтра нам приходит требование это изменить.
Если код читаем и бизнес правила из него легко вывести, то вносить изменения легко. Если домен по коду понять нельзя, то внесение изменений может лишь показаться простым , и то не всегда— в действительности, в таком коде просто трудно даже оценить, правильно ли он делает то, что должен делать
опять же, это подразумевает минимальные изменения в домене, когда ты изначально на 80% правильно смоделировал типы и отношения между ними, и потом ты только уточняешь поведение и структуру типа, причем в основном расширяешь
Shub
что в принципе случается довольно часто, особенно, когда люди не чтут за труд сначала разузнать свою предметку
Roman
ну если вы сильно ошиблись с дизайном домена — это в любом случае тяжело исправить
Roman
просто в некоторых подходах неправильность работы кода более очевидна, а в некоторых менее
Shub
ну в данном случае я не могу сказать, что ошиблись. кто бы мог пять лет назад сказать, что понятие "пользователь магазина" пропадет вообще?
Roman
я понимаю
Roman
Но не понятно, почему вдруг трудно просто добавить новый кейс в юнион тип
Shub
у нас на пользователя ссылалось дофига чего, а щас это просто эфемерный адрес, который мы даже персистить не можем, потому что ES внезапно иммутабельное
Roman
Но не понятно, почему вдруг трудно просто добавить новый кейс в юнион тип
точнее, в каким бы ни был ваш код, внесение и гарантия правильности подобных изменений в код были бы в любом случае огромным гемором
Shub
Но не понятно, почему вдруг трудно просто добавить новый кейс в юнион тип
ну надо различать "трудно" и "невозможно". трудно в основном потому, что потом тебе надо идти по всем местам расширять матчинг, что довольно забавная деятельность, особенно когда у тебя есть вайлдкард матчи - компилятор тебе и не скажет, что "вот тут надо добавить логику для твоего кейса"
Shub
так-то да, в хорошем и знакомом коде все можно
Roman
ну надо различать "трудно" и "невозможно". трудно в основном потому, что потом тебе надо идти по всем местам расширять матчинг, что довольно забавная деятельность, особенно когда у тебя есть вайлдкард матчи - компилятор тебе и не скажет, что "вот тут надо добавить логику для твоего кейса"
ну так тебе пришлось бы заниматься тем же самым, только не матчинг фиксить, а тесты например. А скорее даже и писать новые тесты. Только тут тебе хотя бы компилятор подскажет, где у тебя этот матчинг случается, а в альтернативном сценарии гадать тебе на кофейной гуще, где и что у вас от этого зависит
Shub
ну так тебе пришлось бы заниматься тем же самым, только не матчинг фиксить, а тесты например. А скорее даже и писать новые тесты. Только тут тебе хотя бы компилятор подскажет, где у тебя этот матчинг случается, а в альтернативном сценарии гадать тебе на кофейной гуще, где и что у вас от этого зависит
думаю, что в любом случае и тесты тоже фиксить придется, я еще не видел тестов, которые бы не замораживали конкретную имплементацию
Roman
то, что вайлдкарды повтыкали — плохо, но не смертельно
Shub
но вообще оригинальный поинт был в том, что ДДД скорее мешает в случае exploratory programming - когда инженер изучает домен путем написания кода и сличает реакцию ПМа с эталонной
Roman
думаю, что в любом случае и тесты тоже фиксить придется, я еще не видел тестов, которые бы не замораживали конкретную имплементацию
придется конечно. Я просто к тому, что ваша текущая проблема не была бы меньше, не будь у вас этого ддд. Просто в самом домене случилось очень серьезное изменение, и от такого ни в каком коде защититься фундаментально невозможно
Anonymous
Anonymous
Даже Влашин не писал ничего.
Shub
придется конечно. Я просто к тому, что ваша текущая проблема не была бы меньше, не будь у вас этого ддд. Просто в самом домене случилось очень серьезное изменение, и от такого ни в каком коде защититься фундаментально невозможно
так у нас по сути нет ддд. у нас он есть типа по форме, проявляется в дичайших названиях неймспейсов.
Roman
но вообще оригинальный поинт был в том, что ДДД скорее мешает в случае exploratory programming - когда инженер изучает домен путем написания кода и сличает реакцию ПМа с эталонной
ддд всего лишь про то, насколько по твоему коду легко восстановить доменные правила, только и всего
Shub
в остальном это классический big ball of mud. но говорить об этом - жесткое табу
Roman
так у нас по сути нет ддд. у нас он есть типа по форме, проявляется в дичайших названиях неймспейсов.
но это же не проблема самой идеи, это проблема имплементации. Ну и разруха не в клозетах, а в головах вдобавок
Shub
ддд всего лишь про то, насколько по твоему коду легко восстановить доменные правила, только и всего
нашей команде важно, чтобы было легко двигать тикеты по спринт бордам, мелочи типа доменных правил, а тем более их ясности - это ниже нас