Продолжаем тему нейминга. Неплохой и местами капитанский доклад https://youtu.be/KHgftXIlGsY

Вы обсчитываете свои изменения по скарфу? Тогда мы идем к вам!)

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

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

Петя, из-за тебя релиз вышел на три дня позже срока и всем пришлось работать до ночи. Заказчик был очень недоволен. Разве сложно написать три строчки кода, чтобы покрыть изменения после фикса бага?

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

Как это исправить? Для этого умные люди придумали SCARF-модель, которая построена на удовлетворении 5 критически важных для мозга социальных потребностях: статус, определенность, автономность, принадлежность и справедливость.

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

Опустим закадровое желание побить Петю и посмотрим, что дает такая формулировка:
🔹+2 к статусу ("без тебя не смогли", "нам важна твоя работа")
🔹+1 к определенности (ты, конечно, налажал, но мы тебя не выгоняем)
🔹0 про автономность (увы)
🔹+1 к принадлежности ("команда")
🔹+1 к справедливости (ты что-то сделал, оно привело к таким-то последствиям, вот что тебе нужно сделать, чтобы исправить ситуацию).
Итого: 5 баллов.

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

Захотел загуглить какую-нибудь статью про System Design. Правктически вся выдача про System Design Interview. Такое ощущение, что данный термин стал использоваться только в контексте собесов 😅

Читал вчера статью Маттиаса Верраеса про Segregated Event Layers и внезапно узнал, что это серия статей о паттернах в контексте DDD и Messaging Architecture

https://verraes.net/2019/05/ddd-msg-arch/ Enjoy!

Kenny Baas-Schwegler и Virtual DDD приглашают на встречу с Udi Dahan. Крайне рекомендую послушать. Также есть возможность заранее задать свои вопросы

https://www.meetup.com/virtual-domain-driven-design-meetup/events/294468728/

Хорошая новость: ACM опять договорился с O’Reilly, а заодно с Pluralsight и Skillsoft Percipio. И у них по-прежнему есть скидка для России (стоимость подписки $40 в год).

Плохая новость: Теперь это дополнительная платная опция (+$75 в год), да и курс с тех пор немного вырос.

Предложение теперь не такое заманчивое как раньше, но 1000р в месяц не выглядят такими уж безумными за пакет из 4 подписок (сам АСМ + три сторонних). Одна годовая подписка O’Reilly стоит в пять раз больше.

https://learning.acm.org/skills-bundle

Неплохая подборка видео про DDD и около.

https://x.com/mjovanovictech/status/1695752490069762490?s=46&t=ExJM-wcqikMl9I7JeOzofA

P.S. Из очевидных плюсов – очень понятный по произношению английский 😅

Event Sourcing — это паттерн проектирования в информационных системах, который заключается в сохранении состояния системы путем сохранения истории всех событий, происходящих в системе.

Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет все события, произошедшие с объектом, и воссоздает текущее состояние, используя эти события.

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

➖Хотите узнать подробнее, что такое event sourcing и какие преимущества и недостатки он имеет?
➖Хотите понять, какие трудности могут возникнуть при использовании этой технологии?

Тогда присоединяйтесь к нашему вебинару «Плюсы, минусы и подводные камни Event Sourcing», который состоится 28 cентября в 19:00 МСК

На вебинаре Станислав Щетинников из Сбера подробно расскажет о том, как на самом деле работает event sourcing, какие задачи он решает и какие преимущества он имеет. Мы также рассмотрим недостатки этой технологии и поделимся опытом в использовании event sourcing в реальных проектах.

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

✔️Подробности и регистрация

Вышел новый техрадар https://www.thoughtworks.com/radar

Вижу много интересного – чуть позже будет обзор самых классных новинок (и не только)

Надо брать!)

Всем привет, https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/

Сергей Баранов проводит завтра в канале стрим по ивент штормингу. Сергей, на мой взгляд — самый опытный русскоязычный эксперт по этой теме. Смело рекомендую!

Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»

Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂

Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.

Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).

Like/Share 🙂

Хороший вопрос, сходу не вспомнил, но наверняка было😅

Поделитесь вашим опытом)

https://x.com/xanf_ua/status/1712880028852064762?s=46&t=ExJM-wcqikMl9I7JeOzofA

Начал экспериментировать с англоязычным контентом. Пока в качестве пробного шара перевел свою собственную статью про агрегаты. Шер-подписка ❤️

https://dddevotion.substack.com/p/aggregates

Как я уже писал, вышел новый техрадар. Заметно, что AI, LLM, Generative AI становятся новой нормальностью в индустрии. И если вы еще не погрузились, то крайне рекомендую. Это будет везде.
Вторая большая технология everywhere – Kubernetes. Различным обвесам к нему посвящена значимая часть пунктов нового радара. Сам k8s уже давно стал стандартом. Если вы пропустили рассвет этой технологии – также рекомендую наверстывать.
Но я и сам еще глубоко не копал эти темы, поэтому выделил несколько полезных и понятных для себя «блипов» без k8s и машинлёрнинга. Текста получилось много, попробую написать в комментах.

В пятницу была интересная дискуссия про то как следует коммитить. Я озвучил идею удаления кода, если он не может пройти тесты/линтеры/конвенции. На самом деле это не моя идея, я подсмотрел ее у Кент Бека, но даже не он автор (так бывает у великих художников). Подход называется TCR: test && (commit || revert)

Готовы такое попрактиковать на своей работе?)

Теперь и в наличии)

UPD: электронная версия, по информации из издательства, выйдет через 6-9 месяцев.

https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/