json программисты и xml программирование есть)

это когда ты давным давно пишешь на java а у тебя maven и spring и большая часть вопросов решается правкой xml

сегодня смотрел по куберу видос, там докладчик программировал на YAML

Ребя, правильно ли, если я валидирую входящие данные в дто, в который передаёт контроллер?

Ребя, правильно ли, если я валидирую входящие данные в дто, в который передаёт контроллер?

Ну вообще да, у тебя дто может потом в другом месте использоваться и ты не знаешь будут ли всегда данные уже провалидированы

Понял, спс. Правда в моём кейсе дто некий прокси между сущностью и контроллером, то есть дто живёт только в данный период

Ребя, правильно ли, если я валидирую входящие данные в дто, в который передаёт контроллер?

https://www.yegor256.com/2018/05/29/object-validation.html

Тут поудмал, есть ли смысл при Event Sourcing записывать в Event Store все изменения сущности? Зачем и почему? Скажем у меня юзер, у него 15 полей, поля могу часто изменятся. Но надо ли записывать все? Скажем мне нужен только балланс юзера для соседних сервисов, и на случай дебага, мне не надо знать сколько раз юзер менял свой пароль.

так у тебя получается баланс - отдельная сущность, с ней и работай

Конечно надо

Во первых event consistency во вторых возможность получить актуальное состояние на любой момент времени

Не слишком ли ето много, лишнего?

Во первых event consistency во вторых возможность получить актуальное состояние на любой момент времени

ему не нужно получать актуальное состояние пользователя, только баланса

Об етом и речь, но в будущем может понадобиться и другое поле.

с балансом как с сущностью и работай

Балланс пока как поле у юзера, без доп кошельков и т.д.

Об етом и речь, но в будущем может понадобиться и другое поле.

YAGNI придерживайся

Балланс пока как поле у юзера, без доп кошельков и т.д.

так ты это поле выдели в отдельный класс и с ним уже работай

и делай эвент сорсинг

Вот поетому я и задал вопрос, пока балланс поле у юзера, и вознико вопрос записывать ли другие ивенты

а зачем вообещ ты ES решил использовать?

у меня вопрос уже на этой фразе возник Тут поудмал, есть ли смысл при Event Sourcing записывать в Event Store все изменения сущности

типо ты хочешь менять состояние через domain events но какие то поля без событий, просто в "проекцию" херачить изменения?

да

как то так

но есть ли смысл

ну это полный пиздец, как мне кажется

но есть ли смысл

я тебе уже сказал, выноси баланс в отдельную сущность. Это тебе 100% понадобится

Спасибо

и проблема с эвент сорсингом решится

так у тебя получается баланс - отдельная сущность, с ней и работай

+

у меня вопрос уже на этой фразе возник Тут поудмал, есть ли смысл при Event Sourcing записывать в Event Store все изменения сущности

если так не делать то это уже не ES а что-то другое. Есть ли в этом смысл - определенно есть, просто не надо называть это ES

ну это полный пиздец, как мне кажется

пишем лэджеры на коленке

У меня есть класс фреймворка, имплементящий какой то свой интерфейс. Я добавляю ему необходимый мне функционал (класс расширяемый), а так же интерфейс под этот функционал. Классов таких много. И вот вопрос - нужно ли мне создавать абстрактный класс-родитель для всех моих классов (вроде прослойки между родительским классом фреймворка и моими наследниками), что бы гарантировать, что каждый мой класс будет имплементить необходимый функционал? Т.к. я попросту могу забыть заимплементить в одном из наследников мой интерфейс

а забыть заэкстендить не можешь?

могу)

тогда в чем профит?)

выход из положения - проверять что класс является инстансом интерфейса в каком то одном месте?

зачем?

У меня есть класс фреймворка, имплементящий какой то свой интерфейс. Я добавляю ему необходимый мне функционал (класс расширяемый), а так же интерфейс под этот функционал. Классов таких много. И вот вопрос - нужно ли мне создавать абстрактный класс-родитель для всех моих классов (вроде прослойки между родительским классом фреймворка и моими наследниками), что бы гарантировать, что каждый мой класс будет имплементить необходимый функционал? Т.к. я попросту могу забыть заимплементить в одном из наследников мой интерфейс

зачем асбтрактный класс, можно интерфейс, который экстендит другие интерфейсы

зачем?

а как мне иначе гарантировать, что класс имплементит интерфейс

просто у тебя что абстрактный класс, что интерфейсы имеют те же проблемы и делают одно и то же

более того, абстрактный класс может разрастись, когда интерфейсов станет больше - а разве все они нужны всем классам?

а как еще

Там не только про js получилось

слишком мало графиков, а читать мне было лень)

ладно, тогда прочту

ладно, тогда прочту

Ну по диагонали поглядеть)

а как еще

я бы делал интерфейсы и не любил себе мозги

ну ок

Привет, помогите разобраться, пожалуйста. Обдумываю паттерн saga, возьмём пример, где резервируются деньги у пользователя, куда именно сохраняется информация о резерве, чтобы например из другого потока знать, что стоит резерв? Просто если в хранилище записать, то в случае факапа приложения, данные будут не консистентны немного. Спасибо.

Немного не консистентны это как немножко беременна ? Тут либо есть проблемы либо нет

Привет, помогите разобраться, пожалуйста. Обдумываю паттерн saga, возьмём пример, где резервируются деньги у пользователя, куда именно сохраняется информация о резерве, чтобы например из другого потока знать, что стоит резерв? Просто если в хранилище записать, то в случае факапа приложения, данные будут не консистентны немного. Спасибо.

что значит "в случае факапа"?)

обычно саги комбинируют с доменными ивентами, и когда тебе приходит ивент "деньги зарезервированы" то это уже факт, состояние на момент этого ивента уже консистентно и ты сможешь всегда по стриму ивентов восстановить стэйт

в том числе стэйт саги

но вообще сложно не зная всей задачи)

Саги не обеспечивают консистентность сами по себе. Но они могут обеспечить фолбек

ну их задача по сути описание процесса, бизнес операция

а там уж как организовал процесс)

ERROR: S client not available

ну я к тому, что рейс кондишн они не решают

Привет, помогите разобраться, пожалуйста. Обдумываю паттерн saga, возьмём пример, где резервируются деньги у пользователя, куда именно сохраняется информация о резерве, чтобы например из другого потока знать, что стоит резерв? Просто если в хранилище записать, то в случае факапа приложения, данные будут не консистентны немного. Спасибо.

https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/ мне помогло разобратся

Небольшой вопрос по интерфейсам - предположим, у меня есть один жирный интерфейс, методов на 30. Его было бы неплохо разбить на интерфейсы поменьше, тем более что логически там методы хорошо группируются пачками по 5-6 штук. Вынести из этого интерфейса методы в интерфейсы поменьше, и унаследовать потом его от нескольких мелких интерфейсов - это норма?

зависит от твоих целей

если ты хочешь потом переводить все классы, реализующие исходный интерфейс, на реализацию мелких интерфейсов, но не можешь сделать сразу - норма

в другом случае - а смысл?

если ты хочешь потом переводить все классы, реализующие исходный интерфейс, на реализацию мелких интерфейсов, но не можешь сделать сразу - норма

Т.е. в каждой отдельной части кода проверять обект на выполнение только того мелкого интерфейса, чей функционал в этой части кода нужен?

Т.е. в каждой отдельной части кода проверять обект на выполнение только того мелкого интерфейса, чей функционал в этой части кода нужен?

я не совсем понял, что ты имеешь ввиду, но что-то вроде этого, да нет смысла разбивать интерфейс потому, что его методы логически ложатся в более мелкие группы

Т.е. в каждой отдельной части кода проверять обект на выполнение только того мелкого интерфейса, чей функционал в этой части кода нужен?

всегда так делаю и не жалею

если реализации этого интерфейса не всегда нуждаются во всех-всех его методах - тогда смысл есть

ладно, есть смысл и тогда, когда реализации используют +- все методы но тогда возникает вопрос "интерфейс ты разделил, а классы почему такие жирные?"

Логично. Есть что обдумать, спасибо за советы

я не совсем понял, что ты имеешь ввиду, но что-то вроде этого, да нет смысла разбивать интерфейс потому, что его методы логически ложатся в более мелкие группы

а как же Interface segregation principle

а как же Interface segregation principle

мы тут и говорили о разделении, что тебе не нравится?

а как же Interface segregation principle

я уточнил ниже

разбивать интерфейсы "по логике" содержимого - нет смысла разбивать по логике их использования - есть смысл

а как же Interface segregation principle

это о том что бы проектировать интерфейсы под клиент. Что бы у тебя под клиентский код был ровно тот интерфейс (и тот контракт) который удобен клиенту.

ты не можешь говорить о ISP не описывая то, как интерфейс используется

интерфейс на 30 методов хоть и может соблюдать SRP явно нарушает ISP (потому что я не могу представить себе ситуацию когда все эти 30 методов понадобятся в рамках одной операции)

SOLID єто ж не панацея, если видеш что чтото нарушается и ты понгимаеш зачем єто нужно то єто - ok

чаще всего это не ок, но выхода нет

SOLID єто ж не панацея, если видеш что чтото нарушается и ты понгимаеш зачем єто нужно то єто - ok

нет. не так

Не видел чтобы SOLID нарушался и это было ок. Чаще всего это приводит к неприятным последствиям. Ты идешь на риск в любом случае имхо.

Не видел чтобы SOLID нарушался и это было ок. Чаще всего это приводит к неприятным последствиям. Ты идешь на риск в любом случае имхо.

я не видел ОК проектов)

где всегда все было хорошо

я не видел ОК проектов)

жиза

и всегда соблюдались прицнипы

ну как бы полностью соответствовать SOLID практически невозможно

ты не можешь соблюсти SOLID банально потому что принципы типа SRP и OCP требуют от тебя полного понимания кто и зачем хочет от тебя изменений. В начале проекта это вообще невозможно, с течением времени ты можешь делать более-менее объективные предсказания но по факту SOLID работает только в ретроспективе.