агрегаторы через него не работают

Из прошлой жизни: это направление pull платежа (как раз наш юзкейс). Есть ещё пушовые (это выплаты) https://st.dengionline.com/docs/25068132/terminal'naya_shema.png

благодарю, подумаю

это самый простой из вариантов с точки зрения агрегатора. Прям эталонные маркетойдные условия, как это обычно бывает в рекламе.

проект - игрушка система - агрегатор платёжка- страйп, например пользователь - задрот из игрушки

Народ, знаком на уровне новичка с процедурным стилем, кто готов потратить время и заработать денег за обучение меня, бестолково, ООП?))

Народ, знаком на уровне новичка с процедурным стилем, кто готов потратить время и заработать денег за обучение меня, бестолково, ООП?))

"заработать денег"... смешно)

разберись для начала со структурным программированием, потом возвращайся.

http://david.tribble.com/text/goto.html - для начала

"заработать денег"... смешно)

То есть для Вас за консультацию/обучение не прикладывая усилий поднять 1000 в час - смешно?

хех

То есть для Вас за консультацию/обучение не прикладывая усилий поднять 1000 в час - смешно?

для начала, ты наивно полагаешь что "обучать кого-то" не требует усилий?) ну а так не то что бы смешно, просто веселит

тебе тут и бесплатно бы помогли, но теперь уж не знаю

ощущение что ты ищешь волшебные курсы

или что на все про все уйдет часа 2-3

тебе тут и бесплатно бы помогли, но теперь уж не знаю

Ответ на вопрос может быть бесплатен, консультативная помощь - нет. Что есть консультация? Я пришёл, не знаю ничего, мне знаток рассказал ответ на вопрос. И да, для знатока это не проблема

всех денег вселенной не хватит, что бы купить пару часиков Фесора

я бы краудфандинг организовал

я бы назвал это "самым бесполезным вложением"

собери краудфандинг и приведи Алана Кея

его будем пытать

проблема в том, что бы понять Алана Кея, придется брать твои курсы по расшифровке его доклада)

а ты случаем не на какой конфе не будешь выступать в ближайшее время? хайлоад там, fwdays etc?

проблема в том, что бы понять Алана Кея, придется брать твои курсы по расшифровке его доклада)

а ты смотрел его доклады?)

а ты случаем не на какой конфе не будешь выступать в ближайшее время? хайлоад там, fwdays etc?

не планировал/не звали

если больше двух месяцев в запасе есть - могу

только тему подскажи

а у тя ж была тема, которую ты хотел рассказать

как же ее, не вспомню

мы с @Lividgreen обсуждали про софт скилы только если, а так я все еще думаю над "историей ооп" или как-то information hiding обыграть красиво но это сложно

за тысячу рублей в час мозг вынесут так, что на всё прочее ни времени, ни желания не останется))

16 евро за консультацию что-то мало =(

ты другое представь, научится чувак вдруг ООП, придет на работу, а там как бы никто так и не пишет

деньги на ветер, только расстроится

ты другое представь, научится чувак вдруг ООП, придет на работу, а там как бы никто так и не пишет

слишком утрируешь)

деньги на ветер, только расстроится

ну тоже не плохо ?.

поймет как не нужноделать

пускай битрикс скачает и поймёт как не нужно делать)

ну тоже не плохо ?.

такое ощущение, что ты в каждом чате)

@fes0r , ну мы не совсем про софтскилы говорили, там скорее тема была "как перестать волноваться и полюбить битрикс" :)

софтскилы это же "люби ближнего джуна", "коммуницируй вместо работы" и "не ругайся матом в голос"

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

Привет. А тут только ООП или паттерны/архитектуры тоже обсуждаются?

обсуждаются, ещё и про то что ООП-отстой и победит функциональщина

Поскольку никто не знает, что такое ооп, то говорим про все

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

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

и ответ "зависит от задачи" а точнее "зависит от поведения которое нам необходимо"

и ответ "зависит от задачи" а точнее "зависит от поведения которое нам необходимо"

Ну зачем ты так быстро всё сломал. ?

/link@yetanotherstatsbot

https://b.yasb.exileed.com/telegram/chat/1001071233926

Квадрат и прямоугольник - это специализация (или уточнение) формы (shape)

Как вариант :)

Такая история: я уволился, благо накопления позволяли. Ну и уселся за DDD. Само собой, подтянулись CQRS, ES и слои, и порты-адаптеры. И теперь, найдя новую работу, не могу нормально решать задачи, потому что "страшно" совершить архитектурную ошибку. Раньше как? Ну завернул что-то в декоратор, где-то захардкодил - задача решена, заказчик счастлив, я тоже счастлив. А теперь у меня ступор при поступлении простейших задач. Ах, надо правильно спроектировать. Ах, надо ubiquitos language. Ах, бизнес-логика отравлена инфраструктурой. Блин. И не могу вернуться к старым CRUD прокладкам между UI и DB, которые я называл "приложениями". Что делать? Как перестать DDD и начать жить?

Такая история: я уволился, благо накопления позволяли. Ну и уселся за DDD. Само собой, подтянулись CQRS, ES и слои, и порты-адаптеры. И теперь, найдя новую работу, не могу нормально решать задачи, потому что "страшно" совершить архитектурную ошибку. Раньше как? Ну завернул что-то в декоратор, где-то захардкодил - задача решена, заказчик счастлив, я тоже счастлив. А теперь у меня ступор при поступлении простейших задач. Ах, надо правильно спроектировать. Ах, надо ubiquitos language. Ах, бизнес-логика отравлена инфраструктурой. Блин. И не могу вернуться к старым CRUD прокладкам между UI и DB, которые я называл "приложениями". Что делать? Как перестать DDD и начать жить?

DDD это по сути перенос знаний о предметной области в код. Когда ты начинаешь работать с проектом ты не знаешь предметную область (иначе тебе было бы не страшно, так?). Знания ты приобритаешь со временем и идея заключается в том что бы со временем эволюционировать твою архитектуру.

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

Потому просто пиши код

и не забудь рефакторинг подтянуть

и тесты

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

ну и вместо DDD лучше инвестируй в штуки типа GRASP/SOLID. DDD - сложно, это не про разработку даже. А вот через GRASP/SOLID, да еще и в ретроспективе (то есть не пытаться проектировать так а пытаться так рефакторить) - намного проще добиться того же результата.

p.s. А ты уверен что ты начинал DDD а не просто "делал репозитории для анемичных сущностей и смотрел видосы Янга по ES"?)

p.s. А ты уверен что ты начинал DDD а не просто "делал репозитории для анемичных сущностей и смотрел видосы Янга по ES"?)

Ну как и все я так и начинал. Сейчас повеселее - появилось поведение, Domain Events, aggreate roots. А ES я решил не трогать, уж больно это сложным мне показалось (CQRS можно и без ES).

есть в grasp клевая штука - protected variations. Оно же open/close в solid. Оно же information hiding. Суть которой сводится к тому что "не важно что и как ты делаешь, главное что бы потом можно было передумать и это было бы не больно"

а так я сам пока es не юзаю почти, только cqrs пытаюсь

главное шинами всякими не обмазываться

главное шинами всякими не обмазываться

А что с шинами не так? CommandBus - отличный паттерн. Все сервисы в слое приложения можно шлёпать по кальке. Когнитивная нагрузка снижается.

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

А что с шинами не так? CommandBus - отличный паттерн. Все сервисы в слое приложения можно шлёпать по кальке. Когнитивная нагрузка снижается.

1. что у тебя в сервисах таких?) 2. что тебе мешает их шлепать по кальке?) 3. что возвращает шина?)

вместо прямого вызова надо сделать команду, добавить в роутер шины и только потом добавить хендлер команды. Зачем и почему особо не ясно

вместо прямого вызова надо сделать команду, добавить в роутер шины и только потом добавить хендлер команды. Зачем и почему особо не ясно

ну как зачем, что бы у тебя "шина" скрывала брокер сообщений и "хэндлеры" крутились в своих процессах)

но только тебе это обычно не нужно

а ты сам делаешь блог, ыыыы

1. что у тебя в сервисах таких?) 2. что тебе мешает их шлепать по кальке?) 3. что возвращает шина?)

1. Только оркестрация компонентами модели. 2. Ну да, в общем-то, ничего. 3. Ничего.

1. Только оркестрация компонентами модели. 2. Ну да, в общем-то, ничего. 3. Ничего.

вот третий пункт - очень большое ограничение которое по факту будет тебе в большинстве случаев только мешать

да еще и неправильное)

да еще и неправильное)

ну на счет правильного и не правильного я бы это за бортом беседы оставил

вот третий пункт - очень большое ограничение которое по факту будет тебе в большинстве случаев только мешать

Если паттерн не подходит - можно его не использовать. ) А на практике это не совсем и проблема, по-моему.

Если паттерн не подходит - можно его не использовать. ) А на практике это не совсем и проблема, по-моему.

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

но это к вопросу о конгнитивной сложности - это намного "сложнее" чем просто дернуть метод

который например вернет тебе айдишку

просто CQRS у многих отождествляется с булшитами вроде шин команд и еще более наркоманскими шинами запросов