Vasily
типа module CreditCard=...
Roman
реальный код по модулям я разнесу, но на презентации нужно будет людям как-то дать биг пикчер
Shub
а если этот жсон — контракт между микросервисами, некоторые из которых написаны не на фшарпе, и там нет ду?
если ты базируешься на ddd made functional, то там дто приведен как пример отвязки от транспортного формата. если ты знаешь, что у тебя всегда будет жсон, то твои дто вполне могут быть неявными, я лично вижу мало смысла в генерации такого кода
Shub
и безотносительно дто\без дто, метод validatePaymentMethod явно проблемный.
Shub
сделай с ним что-то и для примера сойдет
Shub
ну может нейминг там
Vasily
Я бы validatePayment разнес на цепочку етодов
x
я допускаю валидацию бизнес правил. скажем, проверять, что чек не выписан самому себе
У меня ещё одно возражение: что если таки не валидно. Бросать эксепшон из конструктора? Вернуть result с ошибкой ведь нельзя.
Shub
Shub
на рекордах методы - просто аугментация, они могут возвращать что хочешь
Romɑn
!!!!!
Romɑn
x
на рекордах методы - просто аугментация, они могут возвращать что хочешь
Думал, ты про конструкторы классов
Shub
ну или что именно ты предлагаешь раздробить?
ну там явно проверки на нулл и пустые строки можно убрать в конструкторы дто, что сократит функцию
Roman
ну там явно проверки на нулл и пустые строки можно убрать в конструкторы дто, что сократит функцию
можешь семпл скинуть? Я че-то не догоняю, как это должно выглядеть
Shub
Думал, ты про конструкторы классов
ну у него ж рекорды, у них нет конструкторов. есть просто конвенция насчет static member Create\New
Viacheslav
Shub
можешь семпл скинуть? Я че-то не догоняю, как это должно выглядеть
у тебя в примере нет разбора жсона
x
ну у него ж рекорды, у них нет конструкторов. есть просто конвенция насчет static member Create\New
А, я не знал. Плохо быть лохом в эфшарп
Shub
если у тебя парсинг жсона просто вызов Json.DeserializeObject<DtoType> - то вот тут как раз стоит проверять на пустые строки и сразу же сигналить назад, что не то прислали
Roman
у тебя в примере нет разбора жсона
ну там рекорды климутабл, жсон в них десериализоваться будет
Shub
десериализация разная бывает
Roman
если у тебя парсинг жсона просто вызов Json.DeserializeObject<DtoType> - то вот тут как раз стоит проверять на пустые строки и сразу же сигналить назад, что не то прислали
но правила нетривиальные — иногда они поля должны быть, иногда другие. Нельзя все нот нулл требовать
Shub
я считаю, что невалидные значения транспортного уровня надо ловить как можно ближе к транспортному уровню, а не пытаться отсигналить откуда-то из ядра луковки
Shub
но правила нетривиальные — иногда они поля должны быть, иногда другие. Нельзя все нот нулл требовать
я тебе предлагаю такую метафору: клерк в окошке приема документов
Shub
клерк следит, чтобы документ был правильно заполнен - без пропусков, без помарок. если это не так - клерк орет и кидает тебе документы в рожу
Roman
для этого клерк должен знать доменные правила
Roman
то есть это не то, когда ты в число попытался строку записать
Shub
то есть это не то, когда ты в число попытался строку записать
у тебя статическая типизация, это вообще исключено
Roman
я про жсон
Shub
я тоже
Крылатый
Сначала подумал, что на фото один человек, и ща будет история как он скрывался под видом женщины
Будешь смеяться, но бабахи так и бегали из окружения через корридоры пропуска гражданских.
Vladislav
У меня ещё одно возражение: что если таки не валидно. Бросать эксепшон из конструктора? Вернуть result с ошибкой ведь нельзя.
Приватный конструктор и метод create
Shub
но даже если это возможно, то парсинг - самое время для проверки
Shub
и только если документ заполнен - клерк складывает их в стопочку от других посетителей и потом несет всю стопочку в бухгалтерию
Крылатый
Будешь смеяться, но бабахи так и бегали из окружения через корридоры пропуска гражданских.
Т.е. брились, надевали юбки (харам же) и прикидывались женщинами.
Shub
орать на клерка в бухгалтерии бессмысленно - посетитель мог выйти из приемной
Shub
орать на просетителя из бухгалтерии тоже бессмысленно - можно не докричаться
x
и только если документ заполнен - клерк складывает их в стопочку от других посетителей и потом несет всю стопочку в бухгалтерию
По влашину эти доки в бухгалтерии должны превратиться в другие доки, вроде как )
Roman
всего лишь правила заполнения документов
если пеймент метод кеш, то чек инфо и кредит карт инфо должны быть пустые. Если метод кредит кард — то должно быть только кард инфо. Это все должно быть на транспортном уровне?
Shub
твоя валидация может быть отделена от фронтенда очередью, разными там кафками и прочим
Shub
если пеймент метод кеш, то чек инфо и кредит карт инфо должны быть пустые. Если метод кредит кард — то должно быть только кард инфо. Это все должно быть на транспортном уровне?
как тебе уже сказали, это лучше представлять через DU
Shub
т.к. это взаимоисключающие варианты
Roman
так оно в домене так и представлено
Roman
но мне, допустим, это надо отправить в сишарпный микросервис
Roman
у них нет ду
Roman
что предлагаешь?
Shub
type PaymentMethodDto =
{ CreditCardInfo: CreditCardInfoDto option
ChequeInfo: ChequeDto option
PaymentMethodType: PaymentMethodType }
Shub
вот это заменить на DU
Shub
у тебя 66% полей optional
Hog
Shub
твой слой сериализации будет производить нужный документ
Roman
да, и в контракте вот такой жсон, который 1 в 1 соответствует дто, которую я написал
Shub
тебя беспокоит, что ты не сможешь производить жсон в одну строчку, что ли?
Roman
ну пока я не понимаю, как условный ньютонсофт мне распарсит это в ду
Shub
ньютонсофт разумеется не распарсит в соответствии с контрактом. и никто не распарсит, тебе придется это пилить самому
Shub
что не так уж и сложно
Roman
пилить десериализацию для каждого доменного типа отдельно, так?
Shub
для дто
Roman
ну ок, для каждой отдельной дто
Shub
тебе придется ее пилить все равно, т.к. контракты имеют тенденцию меняться
Roman
чем это отличается концептуально от того, что я написал? То же кол-во кода, те же правила, только называется deserializePaymentMethod а не validatePaymentMethod
Shub
сейчас ты подстраиваешь свой дизайн под конкретную версию реализации одной конкретной библиотеки
Roman
хотя хз насчет кол-ва кода, скорее всего десериализаторы такие писать дольше
Shub
чем это отличается концептуально от того, что я написал? То же кол-во кода, те же правила, только называется deserializePaymentMethod а не validatePaymentMethod
концептуально это отличается тем, что у тебя явный контракт транспортного уровня выполняется неявно основываясь на предположении, что выбранная библиотека сериализации выдает нужны формат магически
Shub
что как бы странно с точки зрения дизайна
Shub
и если ты с этим аспектом согласен, то проверка примитивных типов в слое сериализации имеет смысл, особенно с учетом проблемы того толстого метода
Roman
я не понимаю, почему ты считаешь, что у меня явный контракт выполняется неявно
Roman
и под какую библиотеку как я подгоняю свой дизайн
Shub
потому что у тебя дто структурированы так, чтобы ньютонсофт производил оговоренный с третьей стороной жсон, по твоим словам