Надо брать!)

Всем привет, 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/

Когда речь заходит про корзины, то мне сразу вспоминается этот доклад https://www.youtube.com/watch?v=KkzvQSuYd5I

кажется, я его уже постил. Ну да.... А что вы, как говорится, мне сделаете?) всем хорошей пятницы 🛒

Вместо страшилки на хелоуин. Зумеры переизобрели Classic ASP (или JSP, кому что ближе)👻

Извините, сегодня не про DDD, но я уверен, что наша индустрия безвозвратно меняется. И проблемы которые мы обсуждали последнее время просто перестанут быть актуальными.
Например, создание кастомной GPT – нам больше не нужна база знаний, мы все наши знания (в том числе код) загрузим в GPT. И любой разраб сможет писать туда вопросы и новые знания. И доменные эксперты тоже. Причем они смогут не только загружать ответы, но и спрашивать «а как оно сейчас-то реализовано?»
Очень резонировал спич Сатьи про инфраструктуру – да, кто-то должен думать про электричество и сервера, но в итоге мы поднимаемся по слоям абстракций все выше. И новый уровень программирования уже на пороге. Только не понимаю пока что, какое знание/ценность условный я буду добавлять.

https://www.youtube.com/watch?v=U9mJuUkhUzk

Недавно Ахтям Сакаев поделился своим взглядом на агрегаты, рассказал какие проблемы он решал и к каким решениям пришел. https://youtu.be/WTu7EgYFYGU

Если вы из мира дотнет, или просто стараетесь отслеживать технологии вокруг, то не пропустите релиз дотнет 8 и конференцию https://www.dotnetconf.net

Команда платформы утверждает, что перформанс для них чуть ли не цель номер один. Отсюда столько всего про оптимизацию.

1. Native AOT - худые бинарники и быстрый запуск.
2. Dynamic PGO и прочее.

Ну и куча других докладов про новый c#12, ef8, blazor, etc.

Сегодня в Лиссабоне завершается очередной websummit. Если в том году были стенды AWS, Google, MongoDB и других технических компаний, то теперь от разработческого осталось только трек FullSTK. Надеюсь, что это связано с неудачными заявлениями ex-CEO вебсаммита и на крупнейшей технологической конфе будет место разработчикам.

Уже в этот четверг к нам в гости придет Влад Хононов, автор книги «Изучаем DDD — предметно-ориентированное проектирование»

Получить ссылку на трансляцию👈

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

Возможно, вы уже читали его книгу «Что такое предметно-ориентированное проектирование?», которую мы недавно перевели для вас и выложили на сайте Systems.Education — читать👈

Хотите задать вопросы по книге или узнать о DDD из первых рук? Приглашаем всех.

Кому может быть особенно интересно:

🧑‍💻Разработчику корпоративного программного обеспечения

👩‍💻Системному аналитику

👨‍💻Архитектору ПО

Начало в 19:00 МСК
Интервью на русском языке.

Получить ссылку на трансляцию👈

Domain-Driven Design — подход к проектированию систем, основанный на создании в проекте общего языка между заказчиками и разработчиками. Этот язык используется как для моделирования предметной области, так и для создания и именования объектной структуры программной системы, включая разбиение её на части, что особенно актуально для современной разработки.

Получить ссылку на трансляцию👈

Отличный алгоритм от Ивана @emacsway

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

Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу.

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

1. На работу выхожу, когда есть минимум два оффера на руках. По второму офферу чистосердечно договариваемся как о резервном. Это важно. Не нужно думать, что если отказаться в последний момент, то удастся сохранить отношения. Если они на вас рассчитывали, то назад уже не примут. Я проверял.

2. На новом месте есть три месяца, чтоб осуществить изменения. Если за три месяца не удалось, то уже вряд ли получится. Нужно менять работу. В РФ это делать болезненно, ибо остается запись в трудовой, поэтому испыталку лучше оформлять по ГПХ. В Европе многие программисты работают как предприниматели, поэтому там проще: не понравилось - ушел, и никому об этом не говоришь просто.

3. На новом месте нужно пустить корни. Провести встречи 1to1 с программистами, понять кто и что из себя представляет. Выбрать костяк, узнать их проблемы, чем-то помочь и заручиться их поддержкой.

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

4. Важно. В этот момент у многих появляется желание продемонстрировать руководству, что они не ошиблись, наняв вас. И делают это "блеснув своей эрудированностью" на фоне предшественников, мол, система - гавно, и как вам повезло, что меня наняли, чтоб я её оценил и это сказал. Эффект прямо противоположный. Руководство это понимает так, что "ты - лох, тебя все это время разводили на бабло, и теперь благодаря мне все узнают какой ты лох". Один из умнейших спецов, которого я когда-либо знал, продержался всего сутки в компании, куда я его пригласил.

5. Итак, поддержка есть (мы же сформировали костяк, да?). Всегда найдутся недовольные, которые постараются подорвать авторитет неуважительными выходками. Шопенгауэр в помощь. Языком нужно владеть. Деликатно, острослово и пропорционально поставить выскочку на место. Важно не перегнуть и вовремя протянуть руку, когда человек "уже все понял". Обычно после одного-двух прецедентов больше желания ни у кого не возникает - включается внешний конформизм. Но если это сделать до формирования костяка поддержки, то есть риск попасть в опалу. Поэтому всегда нужно взвешивать силы поддержки и силы сопротивления.

6. Внимательно прислушиваемся к среде. Обычно там, где не хватает знаний, возникают конфликты, особенно на Code Review. Разруливаем конфликты путем интервенции знаний, чем зарабатываем авторитет. Пару раз подсказать - потом сами спрашивать начнут.

7. Противоречия между руководителями - это ваш ресурс. Читаем "Дао Лидера" Джона Хейдера, или Дао Де Цзинь в оригинале. Изучаем диалектику во всех её проявлениях. Учимся использовать эти внутренние противоречия для синтеза. Если этого не сделать, то есть риск скатиться в донкихотство. На этом этапе вы из себя силы пока еще не представляете. Поэтому, находим заинтересованные стороны действующих сил. Тонкая политика. Но мы архитекторы, а архитектура - есть суть разрешение противоречий. Если арх умеет их разрешать, ему не важно, это противоречие требований или противоречие между двумя топами.

8. Выявляем проблемы, по принципу Парето определяем с какой проблемы начать. Смело и решительно решаем выбранную проблему. Дерзновенно, твердо, буйно и радостно.

Если решили проблему менее чем за три месяца - ура, кредит доверия оправдан. Если не решили - бывает. Я в госах тоже не смог ничего изменить. Тогда нужно уходить на резервный оффер - дальше будет хуже. Я проверял. Kent Beck изменил индустрию, но не смог ничего изменить в Facebook. А Eric Evans написал свою книгу по DDD в порыве отчаяния, как финальный аккорд.

Если удалось осуществить изменения - тогда в помощь:
https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

Это мой собственный алгоритм. У меня это работало. Но это рискованный алгоритм. Я бы сам был бы рад поступать по другому, но не получается.

Сходил на митап про team topologies. Очень благодарен этим ребятам, что подняли тему когнитивной нагрузки. Наши коробочки не бесконечны, как бы это не казалось очевидным)

Если пропустили — рекомендую посмотреть)