https://adr.github.io – а вот как видит процесс ведения адр на своей платформе гитхаб

KanDDDinsky - это европейское сообщество про разработку в целом и DDD в частности. Также они проводят конфу и я очень ждал докладов с последней из них. И вот они начали выкладывать в виде рождественского адвента. Ищите ссылки в твиттере https://twitter.com/kandddinsky 🎉

Буду рад вашим обзорам)

Недавно поболтали про команды – те которые team, а не command 😅 – с ребятами из QIWI в их подкасте DevOne https://devone.mave.digital/ep-12

У меня была уникальная возможность послушать этот доклад на русском😎 Очень интересный подход и свежий взгляд на каплинг)

Друзья, с наступающим (может у кого-то уже всё случилось). Желаю всем в Новом году здоровья, удачи и интересных задач.

Денис Ежов (тимлид и разработчик из Спортмастера) написал (уже третью) статью про свой опыт использования DDD. https://habr.com/en/company/sportmaster_lab/blog/711298/

Принимать решения – это сложно, надо многое учесть и не забыть детали. А еще бы лучше визуализировать процесс принятия решения, чтоб был драфт, который можно обсуждать с коллегами и который можно прикопать как артефакт. Для этих целей придумали кучу канвасов, фреймворков и прочих моделей. А добрые люди собрали это все в одном месте https://untools.co

Отличная подборка статей для погружения в event-driven архитектуру. По-моим ощущениям EDA (или EDM event-driven microservices) уже стала одним из основных подходов в разработке современных сложных систем. Рекомендую погрузиться в эту тему, если вы еще не успели. https://aws.amazon.com/blogs/architecture/lets-architect-designing-event-driven-architectures/

Отличная подборка книг 📚

Robert Laszczak поделился данными о продажах своего кнового курса Go Event-Driven. Такая история успеха безумно мотивирует, но когда осознаешь сколько труда под капотом, ловишь себя на мысли “может ну его”)

Друзья, наверняка, кто-нибудь уже вовсю экспериментируют с chat gpt. Поделитесь интересными находками с точки зрения помощи разработчику)

Люблю доклады @vladik_kh даже не столько за практические советы (которых в его выступлениях достаточно много), сколько за возможность взглянуть на мир разработки через новые призмы.

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

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

Enjoy! https://www.youtube.com/watch?v=1ZyR_tgGTp8

Новый радар вышел. Посмотрим что интересного https://www.thoughtworks.com/radar

Для затравки три блипа
1. https://www.thoughtworks.com/radar/tools/eventcatalog каталог событий. Интересная задумка, надо покопать.
2. https://www.thoughtworks.com/radar/techniques/run-cost-as-architecture-fitness-function Все так или иначе начинают думать про стоимость работы кода.
3. https://www.thoughtworks.com/radar/techniques/zero-trust-security-for-ci-cd весь апрель никому не верь, а ci\cd - не верь никогда)

https://habr.com/en/companies/flant/articles/732152/

Отличный дайджест для #k8s от коллег из Фланта

Всегда интересно почитать про DDD за пределами моего информационного пузыря 🤓

Domain Driven Design

Domain Driven Design (DDD) – на первый взгляд, что-то такое сложное. Да и на второй тоже сложное. Не очень понятно, с чего начинать.

Начать можно со статьи Domain-driven design: рецепт для прагматика.

Автор на примерах проходится по основным концептам DDD:
– ubiquitous language – всё обсуждение происходит в терминах единого языка
– domain model – некий набор сущностей и сценариев, связанных с предметной областью
– bounded context – некие рамочки, в которых существует доменная модель и единый язык

Основная идея DDD – борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде. Domain – предметная область и от неё нужно отталкиваться при проектировании и разработке.
Бороться со сложностью – звучит многообещающе, но "прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design".

Не факт, что будете применять, но знать что это за зверь – стоит. К тому же, можно перенять некоторые полезные практики, например, ubiquitous languge – единый язык общения. На эту тему написан занимательный комментарий, что пример, приведённый в статье из мира продаж всем понятен, тривиален и нет смысла для него составлять ubiquitous languge. На что ему приводят такие термины из мира продаж: ретроскидка, скидка по фактуре, ценовое соглашение, отличное от базового и др. Кажется, не всем понятно. Это я к тому, что использование ubiquitous languge в любой области облегчит взаимодействие.

Можете посоветовать что-то толковое на тему DDD?

#skills

Кстати про нейминг, пропустил отличную статью от коллег из Додо https://habr.com/en/companies/dododev/articles/714512/

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