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

а это не работает, так как программа работает с реальным миром

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

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

ну в большинстве своем достаточно, чтобы типы сходились

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

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

в программировании математика и теория типов - тоже особая

и тоже допускает разные трактовки

ну да, это есть такое, тот же bottom

пример: тайпклассы

если есть клюв - значит птица

но это не всегда работает в реальном мире

еще алан кей пример прекрасный приводил, о ролях

так, стоп, это просто проблема нейминга

вот все говорят, что нейминга

есть есть клюв, то ЕстьКлюв

берем утконоса, он не птица

но у него есть клюв

переименуем клюв у утконоса?

чтоб тайпкласы не нарушать

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

есть есть клюв, то ЕстьКлюв

есть есть клюв, то ЕстьКлюв

а это прекрасное замечание тоже говорит о многом

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

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

ну мы же пишем программы постоянно, мы не формализируем один раз

мы меняем наши формализмы в процессе

и по сути нам нужна птица, а не ЕстьКлюв, так как это семантично

ну это смотря как посмотреть если есть какая-то операция, которая требует клюв и только клюв. Эта операция не должна требовать на вход птицу, она должна требовать на вход HasКлюв. И утконос сюда подходит вполне А есть операция, которая требует клюв и крылья. То есть HasКлюв ∩ HasКрылья, и сюда уже не пройдет утконос.

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

тогда что именно мы програмируем? :)

интернет-магазины

я не понял вопрос)

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

главное чтоб типы сходились

а в задаче стоял вопрос, скажем, накормить птицу... а оказалось, что у нас нет птицы, зато ЕстьКлюв

не-не, вполне понятно что. Интернет магазины продает продаваемое, покупатели покупают покупаемое.

на пхп их гораздо больше

не будем про то, что они выполняют задачу

будем о программировании

как искусстве)

но я так и не понял, какое тайпклассы имеет отношение к тому, что мы неверно что-то формализуем

не-не, вполне понятно что. Интернет магазины продает продаваемое, покупатели покупают покупаемое.

ну тут я под "покупаемое" и "продаваемое" тоже имел тайплкассы/интерфейсы

просто я увидел тенденцию в фп все максимально обобщать

а, хм, возможно твой посыл что это все слишком точно

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

вот под это надо специальную математику

буду пытаться понять эти вещи)

тут есть dotnet'чики из Краснодара?

Есть один в сишарп чате

тут есть dotnet'чики из Краснодара?

Ну я из Краснодара)

- оба эти процесса имеют стохастическую и темпоральную составляющую огласите весь список, ожалуйста!

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

Не, передача действия в then это уже работа вне объекта, это хороший пример открытости для расширения

так весь код работы со значением находится внутри Promise<T>. Я говорю не про то, что код внутри типа промиса, а про то, что наш код какбы помечен эффектом Promise это совсем не то, про что говорил Бугагенко, я об этом уже писал

(прямо как принято делать в фп-языках без ооп, лол)

Несовсем, в жаваподобных языках мы теряем при этом возможность юзать полиморфизм, а в фп с adhoc - нет

в чем ты меряешь жирность классов?

а в чем нужно мерять жырноту класса? в кол-ве капель стекаюшего с класса в минуту?

а в чем нужно мерять жырноту класса? в кол-ве капель стекаюшего с класса в минуту?

ну дальше почитай, можешь мерять в твоих рефакотрингах

будешь его дробить?)

yes

дочитай а потом комменти

мы уже все это обсудили

дочитай а потом комменти

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

и еще как быть с транзакциями в такой системе? когда действия вроде независимы и реагируют на эвенты. но при этом они должны пройти транзакцеонно

или я вообще не въехал?)

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

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

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

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

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

спсибо за ответ. но вот в случае с сервисом, я захожу и явно вижу что при регистрации дернится вип сервис, потом дернится сервис реферала и сервис еще чего то. Что у них там внутри уже может быть и не важно, картина процесса уже у меня грубая есть. а в случае с эентами я должен посмотреть кто подписан на эвент, пойти в его слушатель, найти что делается там, зайти в реализацию метода сущьности и посмотреть какой эвент бросается там, и так по цепочке. Звучит очень неприятно Что может облегчить мне этот путь? Документация?

не приятнее ли например команд бас? так же дает независимость элементам системы

ах ну и еще раз заговорили, нет ли проблем с порядком обработки эвентов?

спсибо за ответ. но вот в случае с сервисом, я захожу и явно вижу что при регистрации дернится вип сервис, потом дернится сервис реферала и сервис еще чего то. Что у них там внутри уже может быть и не важно, картина процесса уже у меня грубая есть. а в случае с эентами я должен посмотреть кто подписан на эвент, пойти в его слушатель, найти что делается там, зайти в реализацию метода сущьности и посмотреть какой эвент бросается там, и так по цепочке. Звучит очень неприятно Что может облегчить мне этот путь? Документация?

как правило поиск причино следственной связи начинается не с ивента. Могу тебе описать что мне обычно нужно было смотреть: - я знаю о каком-то действии, например - что надо email какой-то отправлять. Стало быть я захожу в одно место и смотрю по какому тригеру (ивенту) отправляется мой email и кому. Далее я могу по тригеру определить в каких условиях оно кидается. А еще - эти тригеры очень легко тестировать и они являются частью контракта сущности. - я знаю о каком-то тригере и мне интересно что по этому тригеру происходит. Такое мне нужно знать реже, но иногда надо. В этом случае я могу посмотреть кто подписан на событие и легко определить "следствие" какого-то тригера. - для ситуаций когда у тебя есть процесс включающих кучу бизнес транзакций - у меня обычно всеравно будет одно место где весь процесс описан. Но такое мне нужно было очень редко.

я видимо как то себе не так это представляю ибо опираюсь на знакомые мне реализации. но не похоже ли это на сайд эффекты? вроде произошла регистрация а на самом деле еще куча всего. и одно дело когда эти сайд эфеекты уровня отправки уведомлений\записей логов и т.п. и другое когда это бизнес процессы

я видимо как то себе не так это представляю ибо опираюсь на знакомые мне реализации. но не похоже ли это на сайд эффекты? вроде произошла регистрация а на самом деле еще куча всего. и одно дело когда эти сайд эфеекты уровня отправки уведомлений\записей логов и т.п. и другое когда это бизнес процессы

это просто "еще один вариант" как делать дела. Он не такой явный как скажем прописать все в каком-то координаторе. Но если у тебя одно действие приводит к логике из разных контекстов - может быть полезно

это просто "еще один вариант" как делать дела. Он не такой явный как скажем прописать все в каком-то координаторе. Но если у тебя одно действие приводит к логике из разных контекстов - может быть полезно

так а почему не шина?

так а почему не шина?

потому что "хэнделр команды" будет принадлежать одному контексту, а тебе надо с 5-ю что-то сделать

и да, шина команд вообще никому не нужна

ну только если у тебя обработка команд не асинхронна конечно

короче я понял что я нихуя не понимаю) но спасибо за ответы)

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

когда все на ивентах и не явно - это тоже не удобно

доменные ивенты - это что-то посередине

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

доменные ивенты - это что-то посередине

Как кстати их реализовывать в случае с back-end разработкой?

Не нативные же юзать

погугли)

штука распространенная

штука распространенная

Медиатор?

Не нативные же юзать

смотря что такое нативные)

смотря что такое нативные)

keyword event из самого языка, с подпиской, отпиской и прочими геморроями

Медиатор?

медиатор это медиатор, доменные ивенты это доменные ивенты

keyword event из самого языка, с подпиской, отпиской и прочими геморроями

я хз про какой язык ты говоришь

я хз про какой язык ты говоришь

C#

C#

nservicebus значит можешь взять)

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/domain-events-design-implementation

неужто так сложно погуглить...

тем более как мне кажется эта тема наиболее развита как раз в .net сообществе...

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/domain-events-design-implementation

Читал я это. Предлагают при SaveChanges в EF'е это делать. Что на мой взгляд - зашквар.

Читал я это. Предлагают при SaveChanges в EF'е это делать. Что на мой взгляд - зашквар.

доменный ивент - это факт. Разве у тебя SaveChanges не является коммитом и точкой завершения бизнес транзакции? и разве не только тогда ивенты превращаются в факты?