Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {
originaldata string
newdata string
isModified }
Особенно если апишка частично crudish... И все ради того что бы иметь один метод reservationRepo.save(reservation);
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...
В принципе на бэкенде тоже самое и это кстати важно понимать. Если нет трейсинга, документации/ADR, то понять бизнес будет сложно. Теряется общая картина. И вот сидишь ты и смотришь на все эти месседжи и не понимаешь а какие вообще бизнес процессы тут протекают и что с этим всем делать.
Особенный ад это когда евенты в виде крада... reservationUpdated, listingEdited. Легче застрелиться чем поддерживать такую систему.
Вы правы. Уже 4 года варюсь в message driven/event driven и система все еще продолжает удивлять. От простых ритраев которые спасают и могут и проблемы сделать если нет idempotency, до спайков которые убивают http сервисы или базу потому что воркеры скейлятся намного быстрее и нужно делать circuit breaker и рейт лимиты.
Про параллельную обработку это вообще отдельная тема...
От построения тупого POC до системы которая будет реально работать как часы, как от земли до луны.
Последний раз 3 дня копал почему у нас воркер который работает с раббитом крашится, и месседж остается все время в head и все это повторяется и вообще ничего не может процесситься.
Готовлю статью на медиуме на эту тему. Оказалось для long running CPU bound job драйвер раббита для NODEJS не может отправить heartbeat и раббит закрывает соединение =)))
P.S.
Но справедливости ради нужно сказать, все таки эта архитектура необходима если вам важны данные и важно их процессить, и важно иметь возможность управлять нагрузкой и разделать ворклоады. Если же вы готовы терять реквесты если сервис лежит, и вам не важно что один клиент может повлиять но всех остальных, то может оно вам и не надо...
Когда спрашивают дать ETA основываясь на названии таска ?
Рассматривали ли вы облачные решения, как например snowflake?
Эта статья это стеб?
Не дай бог после таких советов студенты теперь все вычисления будут в конструктор пихать ?
А кто реально видел что бы кто-то использовал эти настройки на живой базе в продакшене ? Я вот не видел :/ А хотелось бы...
Я очень люблю табличные тесты когда не мне их отлаживать в случае поломки. Потому что это ад.
Прикольно, должно экономить время и количество букв в файле. На деле, лишь добавляет логики, усложняет дебаг.
Ну иногда не особа есть выбор. Например когда очень жесткое требование на Exactly once delivery.
Если я не ошибаюсь, решение этой проблемы это хранить оффсеты на стороне консюмера. Что то вроде Outbox Pattern только на входящие сообщения.
Kafka Consumer starts
Load the last offset from the db
Receive message from kafka
tr = Start db transaction
handleMessage(tr)
persistOffset(tr)
tr.commit()
Или все или ничего...
Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {originaldata stringnewdata stringisModified}
Особенно если апишка частично crudish...
И все ради того что бы иметь один метод reservationRepo.save(reservation);
Будет интересно посмотреть на ваше решение.
В закладки. Интересно поиграться.
Мы для эмуляции pub/sub делали эксченжи и присоединяли кьюшки что бы каждая получала копию сообщений. Работает оно, но кьюшки плодятся, мейнтенс...
Стримы интересно выглядят... надо только раббит обновить.
Но в конце концов мы в большинстве флоу переходим на кафку. Все таки partial order of messages и авто ассайн воркеров к партишинам для нас маст хэв.
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Или я что-то не понял?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...
Вы о CRDT?
В принципе на бэкенде тоже самое и это кстати важно понимать. Если нет трейсинга, документации/ADR, то понять бизнес будет сложно. Теряется общая картина. И вот сидишь ты и смотришь на все эти месседжи и не понимаешь а какие вообще бизнес процессы тут протекают и что с этим всем делать.
Особенный ад это когда евенты в виде крада... reservationUpdated, listingEdited. Легче застрелиться чем поддерживать такую систему.
Вы правы. Уже 4 года варюсь в message driven/event driven и система все еще продолжает удивлять. От простых ритраев которые спасают и могут и проблемы сделать если нет idempotency, до спайков которые убивают http сервисы или базу потому что воркеры скейлятся намного быстрее и нужно делать circuit breaker и рейт лимиты.
Про параллельную обработку это вообще отдельная тема...
От построения тупого POC до системы которая будет реально работать как часы, как от земли до луны.
Последний раз 3 дня копал почему у нас воркер который работает с раббитом крашится, и месседж остается все время в head и все это повторяется и вообще ничего не может процесситься.
Готовлю статью на медиуме на эту тему. Оказалось для long running CPU bound job драйвер раббита для NODEJS не может отправить heartbeat и раббит закрывает соединение =)))
P.S.
Но справедливости ради нужно сказать, все таки эта архитектура необходима если вам важны данные и важно их процессить, и важно иметь возможность управлять нагрузкой и разделать ворклоады. Если же вы готовы терять реквесты если сервис лежит, и вам не важно что один клиент может повлиять но всех остальных, то может оно вам и не надо...