дык это ж WPF

Нет, там идея чуток другая вроде была

WPF, previously known as "Avalon", was initially released as part of .NET Framework 3.0 in 2006.

сложно сказать, в чём измерять?

Строки кода, количество проектов

Не надо туда elm

Почему? Redux сейчас пользуется популярностью.

WPF, previously known as "Avalon", was initially released as part of .NET Framework 3.0 in 2006.

avaloniaui это не avalon

Ну не стоит веб практики тащить на десктоп

WPF, previously known as "Avalon", was initially released as part of .NET Framework 3.0 in 2006.

Ну тогда лучше бы он не рождался)

avaloniaui это не avalon

ну я и не говорю про avaloniaui

под десктоп хорошо mvvm заходит

под десктоп хорошо mvvm заходит

Очень спорное утверждение, есть же RN для Android/iOS (это еще не касаясь того факт что десктоп-давно-умер)

Строки кода, количество проектов

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

Очень спорное утверждение, есть же RN для Android/iOS (это еще не касаясь того факт что десктоп-давно-умер)

Концепция reactive streams нормально на mvvm ложится, если что

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

А сколько сущностей \ агрегейшен рутов примерно на каждый DDD сервис?

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

А теперь мы со всей этой фигней попробуем взлететь :)

Это же react, надо срочно наворачивать по верх этого ELM ?

Так уже жи, но для хамарину, можно и tea сделать

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

ну по ДДДшным параметрам сколько всяких сущностей, агрегатов, процессов, вокфлоу?

а, уже спросили

А сколько сущностей \ агрегейшен рутов примерно на каждый DDD сервис?

возьму один сервис для примера: 2 рута, около 10-15 сущностей, но там ещё anti-corruption layer между старым кодом сервиса — его тоже надо по-хорошему допереводить на ДДД

Ну не стоит веб практики тащить на десктоп

Это и не веб, это десктоп

возьму один сервис для примера: 2 рута, около 10-15 сущностей, но там ещё anti-corruption layer между старым кодом сервиса — его тоже надо по-хорошему допереводить на ДДД

А почему не зашла концепция один рут - один микросервис?

Концепция reactive streams нормально на mvvm ложится, если что

А я и не говорю, что MVVM не нужен. До него все работали на MVP/MVC - которые тоже хорошо ложится на десктоп. Надо двигаться в перед и брать хорошие подходы из разных областей.

Вообще хорошо видеть когда весь UI стейт лежит в одном месте, а не размазан по всему компоненту и еще перевязан биндингами и в X(A)ML и в коде, а еще сверху RX - что бы вообще запутаться.

Вообще, я ща скажу крамольную вещь, но ERP системы, например, лучше строить на графовых бд

И ДДД там не очень заходит как концепция

Потому как пользователь может сам определять сущности

А почему не зашла концепция один рут - один микросервис?

может быть неправильно приготовили есть рут1 и рут2 рут2 для массовых операций — т.е. по коллекции рутов1 делает алахай махалаи

Вообще, я ща скажу крамольную вещь, но ERP системы, например, лучше строить на графовых бд

я пока не представляю почему лучше, поэтому не могу комментировать но могу сказать, что даже DDD у нас очень круто зашло

готовил в боевом проекте DDD на C# если есть вопросы, задавайте :)

Сколько человек знает как работает вся система? Сколько человек в среднем на один сервис? Что используется как source of trust?

Сколько человек знает как работает вся система? Сколько человек в среднем на один сервис? Что используется как source of trust?

Суровы вы, Владимир, к человеку :)

=) Это же вопросы, а не претензии)

Ну часть вопросов будет непонятна скорее всего

Сколько человек знает как работает вся система? Сколько человек в среднем на один сервис? Что используется как source of trust?

у нас парное программирование, поэтому знания постоянно шарятся ни один человек сейчас не знает как работает вообще всё, ну, в подробностях, на каком-то высоком уровне абстракции все представляют что и с чем на один сервис по разному бывает, поскольку не всегда надо один сервис тюнить, часто бывает что мы разработали сервис и на пару месяцев о нём забыли пока новые требования не придут но вообще команда у нас 60 человек, около 25 разрабов source of trust — это код :) но наши аналитики читают код и в DDD им понятно что написано в целом

А, большая система

25, КАРЛ

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

КУДА СТОЛЬКО?

Сущности маппить?

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

Он не тролльный

Просто я видел и большие, и маленькие команды

Маленькие работают в разы эффективнее

В больших всякое бывает

у нас есть такая вещь как подкоманды

в рамках подкоманды мы фокусируемся на какой-то предметной области или областях

подкоманда это весь набор ролей, если что, а не только разрабы

Интересно, сколько ваша доменная модель займет кодочасов на F#

очень мало, но человеческая лень непобедима

Тут скорее инерция

по сути помимо меня в проекте ещё один человек за ФП топит, остальные скептически относятся

поэтому по сути у меня сейчас вызов в слеудющем состоит, мне надо в свободное время сделать что-то такое, что впечатлит коллег и замотивирует на изучение ФП :)

у нас парное программирование, поэтому знания постоянно шарятся ни один человек сейчас не знает как работает вообще всё, ну, в подробностях, на каком-то высоком уровне абстракции все представляют что и с чем на один сервис по разному бывает, поскольку не всегда надо один сервис тюнить, часто бывает что мы разработали сервис и на пару месяцев о нём забыли пока новые требования не придут но вообще команда у нас 60 человек, около 25 разрабов source of trust — это код :) но наши аналитики читают код и в DDD им понятно что написано в целом

Про source of trust я имел ввиду данные, у каждого сервиса своя бд с репликацией или есть что-то общее) Также интересно как общение происходит между сервисами, версионирование, есть ли распределенные транзакции

Про source of trust я имел ввиду данные, у каждого сервиса своя бд с репликацией или есть что-то общее) Также интересно как общение происходит между сервисами, версионирование, есть ли распределенные транзакции

у каждого сервиса свои таблицы, но БД сейчас общая — распилить не проблема, просто пока нет нужды репликация есть ,но шардирования нет, потому что MSSQL также у нас есть эластик и кассандра, но там всё проще общение между сервисами либо напрямую по http — у нас своя обёртка на IL коде, которая из интерфейса генерит http-клиент с адаптивной параллельностью и прочими приколами, которые связаны с доступностью и бюджетами времени либо через кафку :)

версионирование — это в контексте чего?

транзакции пока не используем, просто хлам если что в БД остаётся, но на воркфлоу это не влияет понятно, что надо делать, но не сейчас

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

версионирование — это в контексте чего?

Сообщений между сервисами, моделей

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

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

Добавляются или изменяются поля, или логика меняется

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

например, раньше по кейсу вам надо было слать сообщение T с n полями, теперь пришлось расширить до n+m, один сервис должен реагировать по новому остальные по старому.

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

но вообще при интеграции с внешними сервисами придётся решать этот вопрос

О, ещё интересна авторизация у каждого сервиса или одна на входе в систему

её нет :)

её нет :)

упс!

у нас демилитаризованная сетка

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

но, чуваки, у вас вопросы уже не по ДДД пошли :)

Doom's day device?

Doge Driven Development

wow

Тогда вопрос такой - какие из ддд концепций вы успешно использовали, какие не очень успешно

Тогда вопрос такой - какие из ддд концепций вы успешно использовали, какие не очень успешно

Интересный вопрос плюсую

а о каких концепциях речь? их по идее две единый язык и разделенный контекст или вопрос про value object, entity и их реализацию?

Ну хоть какие) Есть ли польза от полного разграничения, отказа от шаренных либ, использование разных названий в разных сервисах

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

также нам очень зашёл подход https://fsharpforfunandprofit.com/cap/

ну на C#, оф кос :)

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

Имел ввиду разных названий одного и того же типа)

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

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

ктулху будет рад

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

единственная ложка дёгтя такая

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

И тесты только по каждому сервису пишете или интеграционные тоже?

вы либо вычитываете дохера всего для агрегата, а вам может это всё не надо — и это лишняя нагрузка, либо обмазываетесь lazy со всеми вытекающими :)

интеграционные тоже

вы либо вычитываете дохера всего для агрегата, а вам может это всё не надо — и это лишняя нагрузка, либо обмазываетесь lazy со всеми вытекающими :)

а можно это как-то объединить с graphQL стилем?

и ещё тесты есть, которые морды тестят через селениум

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

а можно это как-то объединить с graphQL стилем?

вот это не знаю — это для нас следующая точка роста, потому что сейчас мы очень тупо данные передаём

ребят, я отвалюсь на полчасика

спасибо за шару опыта)

Люди, а в последней вижле уже починили Ф# под Кор?

Да, починили (ну, во всяком случае, более-менее оно работает). Однако, похоже, сортировка файлов в проекте не пашет :(

А кто то юзал F# с раздером?

имеет смысл пробовать rider для F#? как он по сравнением с vscode + ionide?

По сравнению со студией (см. выше) — очень ок. Да, code lens нету.

А кто то юзал F# с раздером?

\о