Изучаем DDD
Предметно-ориентированнре проектирование
Влад Хононов
Если сранивать "DDD самое основное" и книгу от Влада, то при сопоставимом объеме книга Влада гораздо полезнее. Мне понравилось, что есть примеры стратегического проектирования на основы поддоменов, с нормальным объяснением чем core от универсального домена отличается.
Понравилось, что приведены основные паттерны для тактического проектирования. Хорошо объяснено про ограничения Transaction Script.
Не очень понравилось как объяснены доменные события и описаны трех-слойная и порты и адаптеры архитектуры, как-то скомкано, без достаточного количества примеров.
По поводу EventSourcing основное сказано, дана оценка по нагрузке и типовые вопросы, все четко и по делу.
В эволюции проектных решений мне не хватило примеров, но в приложениях есть описание примеров использования DDD, что частично компенсирует.
В целом впечатление хорошее - книга годная, охватывает основные вопросы, скорее всего придется еще поискать доп. инфу, но зато как справочник - идеально.
#DDD #книга #отзыв
Предметно-ориентированнре проектирование
Влад Хононов
Если сранивать "DDD самое основное" и книгу от Влада, то при сопоставимом объеме книга Влада гораздо полезнее. Мне понравилось, что есть примеры стратегического проектирования на основы поддоменов, с нормальным объяснением чем core от универсального домена отличается.
Понравилось, что приведены основные паттерны для тактического проектирования. Хорошо объяснено про ограничения Transaction Script.
Не очень понравилось как объяснены доменные события и описаны трех-слойная и порты и адаптеры архитектуры, как-то скомкано, без достаточного количества примеров.
По поводу EventSourcing основное сказано, дана оценка по нагрузке и типовые вопросы, все четко и по делу.
В эволюции проектных решений мне не хватило примеров, но в приложениях есть описание примеров использования DDD, что частично компенсирует.
В целом впечатление хорошее - книга годная, охватывает основные вопросы, скорее всего придется еще поискать доп. инфу, но зато как справочник - идеально.
#DDD #книга #отзыв
👍75❤5
Важное дополнение, как заметили в чате, книга не совсем про ddd, больше чем на половину она включает дополнительные архитектурные темы и шаблоны, но объясняются они через призму ddd.
Мне кажется это гуд, потому что это решает проблему "к пуговицам вопросы есть? Нет? Ну тогда остальное ваши проблемы." Т.е. книга помогает понять не только "что такое ddd", но и помочь в его использовании.
Кстати, Влад правильно высказался про культ "анемичных моделей", за это книге отдельный респект.
Мне кажется это гуд, потому что это решает проблему "к пуговицам вопросы есть? Нет? Ну тогда остальное ваши проблемы." Т.е. книга помогает понять не только "что такое ddd", но и помочь в его использовании.
Кстати, Влад правильно высказался про культ "анемичных моделей", за это книге отдельный респект.
👍45🔥1
"Найду первую работу, а там попрет" - это тот план, который надо сразу выкинуть из головы.
Во-первых, потому что скорее всего не попрет, во-вторых, после устройства на работу самые сложные задачи только появятся.
Рынок устроен так, что 80% сами ищут работу, а 20% приглашают (хантят). Поэтому основная задача попасть из первой группы во вторую.
Если план в том, чтобы всегда искать работу, то вы ставите себя в позицию "ну возьмите меня", а это очень плохо работает на длинной дистанции. Потому что уже на первой работе вы рискуете застрять на полжизни (хороший коллектив, привычные таски, страх что-то менять - это сильно вас затормозит, уж поверьте).
Ну ок, допустим вас взяли на работу, прописали должностные (если вам повезло попасть в нормальное место, где есть должностные), дали хороший оклад и вроде бы жизнь удалась. Но оказывается, что ровно с этого момента вы начали активно деградировать, потому что все новое что вы изучаете - это корпоративные задачи и вещи, выгодные вашему работодателю.
Первое время вам еще предлагают линейные переходы (с мидла, на мидла) и вроде как иллюзия выбора есть. Но через некоторое время и эти предложения иссякнут.
Есть иллюзия, что могут повысить, ведь компания заинтересована в развитии своих сотрудников! Но на практике вы пытаетесь пробиться сквозь менеджмент, который обещает, говорит какой вы молодец, до тех пор пока вы не устанете и не забьете на всякие попытки доказать что хороши.
Никому не надо повышать сотрудников просто так, никому не надо развивать вас как специалиста сверх тех требований, которые есть в компании. Никому кроме вас не интересно качать вашу карьеру и просто устроившись на работу вы не решите следующую задачу - как расти по карьере.
Во-первых, потому что скорее всего не попрет, во-вторых, после устройства на работу самые сложные задачи только появятся.
Рынок устроен так, что 80% сами ищут работу, а 20% приглашают (хантят). Поэтому основная задача попасть из первой группы во вторую.
Если план в том, чтобы всегда искать работу, то вы ставите себя в позицию "ну возьмите меня", а это очень плохо работает на длинной дистанции. Потому что уже на первой работе вы рискуете застрять на полжизни (хороший коллектив, привычные таски, страх что-то менять - это сильно вас затормозит, уж поверьте).
Ну ок, допустим вас взяли на работу, прописали должностные (если вам повезло попасть в нормальное место, где есть должностные), дали хороший оклад и вроде бы жизнь удалась. Но оказывается, что ровно с этого момента вы начали активно деградировать, потому что все новое что вы изучаете - это корпоративные задачи и вещи, выгодные вашему работодателю.
Первое время вам еще предлагают линейные переходы (с мидла, на мидла) и вроде как иллюзия выбора есть. Но через некоторое время и эти предложения иссякнут.
Есть иллюзия, что могут повысить, ведь компания заинтересована в развитии своих сотрудников! Но на практике вы пытаетесь пробиться сквозь менеджмент, который обещает, говорит какой вы молодец, до тех пор пока вы не устанете и не забьете на всякие попытки доказать что хороши.
Никому не надо повышать сотрудников просто так, никому не надо развивать вас как специалиста сверх тех требований, которые есть в компании. Никому кроме вас не интересно качать вашу карьеру и просто устроившись на работу вы не решите следующую задачу - как расти по карьере.
👍130🤔10🔥8❤5👎5🤡5😁1💩1
"А как надо?"
А надо понять свою цель. Если цель устроиться на работу, то это плохая цель, потому что за не ничего нет. Не будет такого, что кто-то за вас начнет ставить новые цели.
Все начинается с момента когда вы начинаете хотеть чего-то еще, а не только "устроиться на работу". Когда появляется "хочу заниматься созданием умных устройств", "хочу строить сложные архитектурные проекты", потом надо разбивать цель на задачи (Event Storming) и когда появится ясность, чего вы хотите, тогда и планов "найду работу, а там как-нибудь что-нибудь придумаю" не будет.
А надо понять свою цель. Если цель устроиться на работу, то это плохая цель, потому что за не ничего нет. Не будет такого, что кто-то за вас начнет ставить новые цели.
Все начинается с момента когда вы начинаете хотеть чего-то еще, а не только "устроиться на работу". Когда появляется "хочу заниматься созданием умных устройств", "хочу строить сложные архитектурные проекты", потом надо разбивать цель на задачи (Event Storming) и когда появится ясность, чего вы хотите, тогда и планов "найду работу, а там как-нибудь что-нибудь придумаю" не будет.
👍59😁10🤡10❤3🔥3💩1
Я не говорю о том, что вы не должны устраиваться на работу. Я говорю о том, что устраиваясь на работу нужно понимать какая работа вам нужна, какие дальнейшие шаги вы будете делать, не засиживаться на уютном месте и т.д.
Самое главное "я пошел куда взяли" - это не стратегия. Вот о чем мои посты. А таких "планов" я встречаю каждый стрим по пять штук. Это не стратегия, не план, это просто "надежда", что все получится само собой.
Самое главное "я пошел куда взяли" - это не стратегия. Вот о чем мои посты. А таких "планов" я встречаю каждый стрим по пять штук. Это не стратегия, не план, это просто "надежда", что все получится само собой.
👍67🤡8🔥7💩1
Субботний стрим 25.11 10:00
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
🔥12👍3
Сегодня вечером в телеграме запланирован техток по карьере программиста. В 15:00 по мск. В формате дискуссии со всеми кто придёт
👍31
Про оптимизацию
Многие начинающие разработчики думают, что зная внутреннюю реализацию (рантайм) языка, можно получить огромный выигрыш в производительности, невзирая на алгоритм работы программы.
Это не так. Общее правило гласит "сильный алгоритм лучше, чем слабый + оптимизации". Оптимизировать на уровне языка имеет смысл только если уже нет возможности улучшить алгоритм, а проблемы с производительностью есть.
На практике в большинстве случаев помогает поиск "сильного алгоритма", при слабом алгоритме байтоебство (за редким исключением) ничего не дает.
Чтобы проиллюстрировать проблему, я привел два скрина с leetcode, перый - это оптимизация от человека, который много лет изучает движок V8 и спеку JS, а второй решение той же задачи "в лоб" от меня.
Как видите, оставаясь в рамках одного и того же алгоритма, значительно усложнив запись кода и используя "технические трюки" добиться значимых результатов не получается.
Поэтому учите алгоритмы, господа. Учите алгоритмы!
Многие начинающие разработчики думают, что зная внутреннюю реализацию (рантайм) языка, можно получить огромный выигрыш в производительности, невзирая на алгоритм работы программы.
Это не так. Общее правило гласит "сильный алгоритм лучше, чем слабый + оптимизации". Оптимизировать на уровне языка имеет смысл только если уже нет возможности улучшить алгоритм, а проблемы с производительностью есть.
На практике в большинстве случаев помогает поиск "сильного алгоритма", при слабом алгоритме байтоебство (за редким исключением) ничего не дает.
Чтобы проиллюстрировать проблему, я привел два скрина с leetcode, перый - это оптимизация от человека, который много лет изучает движок V8 и спеку JS, а второй решение той же задачи "в лоб" от меня.
Как видите, оставаясь в рамках одного и того же алгоритма, значительно усложнив запись кода и используя "технические трюки" добиться значимых результатов не получается.
Поэтому учите алгоритмы, господа. Учите алгоритмы!
👍123🤡11🌚8❤5👎2
Вижу, что предыдущий пост вызывает сомнения у некоторых подписчиков. Давайте я дам другое объяснение.
Итак, у нас есть функция f() которая считает время выполнения нашей программы в некотором окружении. Мы точно знаем,
что эта функция многих переменных, более того, мы точно знаем, что одна из переменных - это O(N), т.е. функция выглядит как-то так:
f(O(N), x1, ..., xn)
Проблема в том, что функция f() на каждом вычисляющем устройстве своя, т.е. на самом деле - это множество функций. И все что мы точно знаем, что O(N) - это тривиальное свойство этой функции, а x1..xn - это нетривиальные свойства, а по теореме Райса проверить наличие нетривиальных свойств функции - невозможно (эта задача неразрешима)
Таким образом, улучшить работу алгоритма гарантированным способом можно только через оптимизацию O(N), в остальных случаях надо брать и рассматривать каждый конкретный запуск отдельно, искать те x1...xn, которые нам нужны (откидывая ненужные) и оптимизировать что-то конкретное, при этом мы никогда не будем уверены, что запуск который мы отпимизировали будет быстрее, чем запуск, который мы не оптимизировали (всегда лотерея).
Собственно мой предыдущий пост как раз об этом - изучая алгоритмы вы получаете хороший инструмент улучшения своего кода, уповая на "технические" оптимизации вы будете в ситуации "может да, а может нет". Поэтому попытки выработать "общие рекомендации как технически улучшить ваш код", которые всегда работают - это утопия. Пишите код красиво и понятно, а не занимайтесь решением "неразрешимых задач".
Итак, у нас есть функция f() которая считает время выполнения нашей программы в некотором окружении. Мы точно знаем,
что эта функция многих переменных, более того, мы точно знаем, что одна из переменных - это O(N), т.е. функция выглядит как-то так:
f(O(N), x1, ..., xn)
Проблема в том, что функция f() на каждом вычисляющем устройстве своя, т.е. на самом деле - это множество функций. И все что мы точно знаем, что O(N) - это тривиальное свойство этой функции, а x1..xn - это нетривиальные свойства, а по теореме Райса проверить наличие нетривиальных свойств функции - невозможно (эта задача неразрешима)
Таким образом, улучшить работу алгоритма гарантированным способом можно только через оптимизацию O(N), в остальных случаях надо брать и рассматривать каждый конкретный запуск отдельно, искать те x1...xn, которые нам нужны (откидывая ненужные) и оптимизировать что-то конкретное, при этом мы никогда не будем уверены, что запуск который мы отпимизировали будет быстрее, чем запуск, который мы не оптимизировали (всегда лотерея).
Собственно мой предыдущий пост как раз об этом - изучая алгоритмы вы получаете хороший инструмент улучшения своего кода, уповая на "технические" оптимизации вы будете в ситуации "может да, а может нет". Поэтому попытки выработать "общие рекомендации как технически улучшить ваш код", которые всегда работают - это утопия. Пишите код красиво и понятно, а не занимайтесь решением "неразрешимых задач".
👍71🔥19💯4🤬1
Басня про математиков и программистов
Решили как-то раз три математика на охоту сходить, да беда в том, что патроны у них старые были. Непонятно какие стреляют, а какие нет.
Подумали они, подумали. И решили патроны в виде функций описать, если патрон стреляет, то функция "истину" возвращает, а если нет, то ложь.
Да вот беда, если запустить функцию, то патрон ломается, и больше не работает.
Пошел тогда первый математик к программисту на JavaScript, говорит, вот функция, напиши программу которая не запуская функцию проверяет что она возвращает. Подумал JS-разработчик, посмотрел функцию, видит, что если в функции встречается переменная "порох", то она вроде истину возвращает, если нет, то ложь.
Написал быстро программу, отдал математику. Математик проверил свои патроны, пошел на охоту. Больше его никто и не видел.
Второй математик пошел к Haskell разработчику, так как не доверял императивщикам. Начали они обсуждать проблему, да только поругались в пух и прах, не сошлись во мнении, что круче монада или функтор. До сих пор не разговаривают, так сильно поругались.
А третий математик никуда не пошел, так как знал про теорему Райса. Купил новых патронов, сходил на охоту, добыл дичь и жил долго и счастливо.
Мораль сей басни такова - хочешь жить долго и счастливо, не связывайся с программистами, особенно если они программируют на Haskell.
Решили как-то раз три математика на охоту сходить, да беда в том, что патроны у них старые были. Непонятно какие стреляют, а какие нет.
Подумали они, подумали. И решили патроны в виде функций описать, если патрон стреляет, то функция "истину" возвращает, а если нет, то ложь.
Да вот беда, если запустить функцию, то патрон ломается, и больше не работает.
Пошел тогда первый математик к программисту на JavaScript, говорит, вот функция, напиши программу которая не запуская функцию проверяет что она возвращает. Подумал JS-разработчик, посмотрел функцию, видит, что если в функции встречается переменная "порох", то она вроде истину возвращает, если нет, то ложь.
Написал быстро программу, отдал математику. Математик проверил свои патроны, пошел на охоту. Больше его никто и не видел.
Второй математик пошел к Haskell разработчику, так как не доверял императивщикам. Начали они обсуждать проблему, да только поругались в пух и прах, не сошлись во мнении, что круче монада или функтор. До сих пор не разговаривают, так сильно поругались.
А третий математик никуда не пошел, так как знал про теорему Райса. Купил новых патронов, сходил на охоту, добыл дичь и жил долго и счастливо.
Мораль сей басни такова - хочешь жить долго и счастливо, не связывайся с программистами, особенно если они программируют на Haskell.
😁149👍13🤡6❤5👏1🤔1🤬1🤣1
Ну что, завтра у нас снова пятница, и может быть стоит провести еще один техтолк? Если да, то пишите темы, на которые хотите пообщаться, в комментарии к этому посту. Побеждает тема, которая наберет больше всего реакций!
👍24🤡1
Сегодня узнал, что Валерий Лис снова вернулся на ютуб, я очень люблю этого автора, за его глубокие знания и техническую компетенцию, а главное за скромный характер. Я помню как несколько лет назад провел всю новогоднюю ночь на его стриме, где он писал программу для отображения фрактала Мандельброта. И это было очень круто!
А еще Лис отлично знает ассемблер и X86 архитектуру, развлекается тем, что с нуля пишет эмулятор процессора и запускает на нем что-нибудь олдовое.
В целом, если хакеры и существуют, то это Лис!
А ссылку на видео я не дам, так как Лис очень скромный и явно этого не одобрит! Виват Лису!
А еще Лис отлично знает ассемблер и X86 архитектуру, развлекается тем, что с нуля пишет эмулятор процессора и запускает на нем что-нибудь олдовое.
В целом, если хакеры и существуют, то это Лис!
А ссылку на видео я не дам, так как Лис очень скромный и явно этого не одобрит! Виват Лису!
👍50👎50😁9🔥4🤡3🤔2💯2
Завтра в 10:00 утрк мск стрим с мурычем.
Я ему скидываю ссылку на зум, он подключается и шарит экран на своём стриме.
Формат - каждый высказывает претензии и даёт свою оценку. Вывод каждый делает сам.
У меня на канале стрима не будет. Но ссылку я, наверное, скину.
Я ему скидываю ссылку на зум, он подключается и шарит экран на своём стриме.
Формат - каждый высказывает претензии и даёт свою оценку. Вывод каждый делает сам.
У меня на канале стрима не будет. Но ссылку я, наверное, скину.
🔥49👍9❤4🤡3