Была похожая ситуация, когда несколько пакетов транзитивно тянули разные версии этого пакета. Для решения проблемы обновился (или даунгрейднулся), чтобы версии были одинаковые.
С полгода назад искал работу: про pet проекты не спрашивал никто: ни HR, ни технические спецы
Справедливости ради: тестовые задания тоже были только такие, какие могут сделаться во временных рамках собеседования. Т.е., домашнюю работу никто не задавал
Автору надо пытаться попасть на какую-нибудь стажировку
Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта
Документация / комментарии / информативное наименование / помощь коллег - это увеличивает скорость и комфорт погружения в проект
var'ы здесь не при чём; они только увеличивают длину строки, а полезной информации в большинстве случаев не несут
Если не поможет, то перейти к чистому SQL для получения целевой выборки
Или даже перейти к хранимой процедуре, к-рая будет и выборку делать и "завершать" записи (если это можно на стороне БД)
По своему примеру: начал читать "синюю книгу" по DDD, помучал и бросил. Через какое-то время попал на проект, где более опытные ребята пытались реализовать DDD. Немного поработав на проекте снова вернулся к "синей книге" - и здесь она уже пошла: я читал книгу, вспоминал проект, понимал/осознавал, как мною прочитанное соотносится с тем, что в проекте.
Похожа картина была когда-то и с шаблонами проектирования: будучи "зелёным" осилил пару-тройку глав. После полутора лет работы книга зашла на ура.
А цель какая: собственной мотивации не хватает, поэтому нужны дополнительные источники (кураторство со стороны / затраченнные деньги и т.п.)? Или корочка нужна?
Книга же про Haskell. Понятно, что базовые принципы можно, наверное, перенести на целевой ЯП (C#, Java у сабжа), но по постановке вопроса также понятно, что это будет излишне сложно. Надо что-то попроще.
Какие паттерны быстро меняются?)) Паттерны проектирования описали несколько десятилетий назад. Архитектурые шаблоны - тоже большой скорости развития не наблюдается.
Эванс?
У него это как-то неубедительно написано)
У нас в проекте события тоже порождают события.
Ведь, например, если события лягут в ту же Kafka, то почему обработчик на другой стороне не может в свою очередь тоже сгенерировать событие и снова положить в Kafka?
Как вариант - отложить и через некоторое время снова попробоват чтение. У меня так было с книгой по паттернам проектирования. Будучи зелёным юнцом я не смог пройти дальше пары глав, т.к. не понимал, про что пишут / какие проблемы пытаются решить. Через полтора года работы книга зашла на ура.
В рамках обучения можно и на 5-ой версии делать приложение, если нашли подходящее руководство. Научитесь, прочитаете статью о различиях, проведёте миграцию на новую версию - и отлично.
Опять же, в рамках обучения, делать на 6-ой версии по руководству от 5-ой не совсем хорошо - будут возникать лишние трудности/вопросы. Конечно, они все решаемы, но будут занимать ваше время и тратить ваши силы на нецелевую активность.
