Всем привет! Мы переходим к третьей части, которая посвящена техникам и софт-скиллам.
А в этом выпуске мы обсуждаем процесс принятия архитектурных решений и очень полезные техники, скрытые за непонятными аббревиатурами ADR и RFC.

Apple
Google
Spotify
Яндекс
Castbox
Overcast
Web

#dddporn #eventstorming😝

Ник Тьюн продолжает привносить новые инструменты в мир разработки и DDD в частности.

В этой статье он описывает DDD-каты. Ката - небольшое, повторяемое упражнение для прокачки своих возможностей и приобретения привычки. Возможно вы делали каты в TDD, архитектуре или даже карате. Теперь можно попробовать и в DDD)

https://medium.com/nick-tune-tech-strategy-blog/strategic-domain-driven-design-kata-delivericious-b114ca77163

Как и что вы рассказываете про DDD своим стейкхолдерам-продактам-проджектам-тимлидам? Какой теоретический минимум нужен для продуктивной работы? Практикуете ли Event Storming? Легко ли менеджеры и стейкхолдеры вовлекаются в подобные активности? Поделитесь опытом 🙏

Давно не виделись) 19 августа в 18-00 проведем очередной митап. Ссылка на трансляцию будет в чате, если хотите поделиться, то вот ссылка на таймпад https://dddevotion.timepad.ru/event/1733246/

Послезавтра проводим митап уходящего лета. И программа получается несколько монолитной) Первый докладчик – Олег Федосеев (@olegfedoseev) из Циан расскажет про вторую жизнь монолита:

Многие думают что монолит можно только переписать или заменить микросервисами, но есть альтернативный путь — постепенное улучшение изнутри и в своём докладе я расскажу как это работает и как к этому можно прийти.

Задавайте вопросы, чтобы мероприятие получилось интересным и полезным https://app.sli.do/event/3xzwxrro

Второй спикер – Андрей Ратушный (@agratushniy). Он расскажет про подход, который позволяет собирать документацию на основании программной модели. Используя этот подход вы увидите, как можно определить дефекты трансляции ментальной модели в программную и какой дополнительный профит мы можем из этого получить.

На днях на хабре вышла расшифровка моего выступления на Russian Python Week 2020 https://habr.com/en/company/oleg-bunin/blog/551428/

Наше сообщество поддерживает компания JetBrains. У меня есть купон на одну из их IDE. Отдам за лучший вопрос! Жду ваших здесь https://app.sli.do/event/3xzwxrro

До встречи на митапе!

Ссылка на трансляцию https://www.youtube.com/watch?v=5Adgq-4KJoo

Друзья, все ссылки, презентации и код будут доступны. Выложу здесь завтра-послезавтра. Спасибо, что были с нами. До новых встреч)

Кстати, самый заплюсованный вопрос был от Сергея про будущее ДДД и без ДДД. Сергей, дай знать в комментах.

Про архитектурные каты – о’рейли регулярно проводит соревнования по катам, можно посмотреть видео с разборами https://learning.oreilly.com/videos/architectural-katas-april/0636920557906/

«Когда метрика превращается в цель, она перестает быть хорошей метрикой». Закона Гудхарта.

Оказывается умные люди полвека назад сформулировали проблему метрик. Что это значит? Если у вас есть метрики по коду и вы должны во что бы то ни стало в нее попасть, то жди проблем. Особенно, если у разработчиков будет зависеть от этих KPI зарплата.

Привет! Нас не было три недели (а никто даже и не спросил почему 😒), но новый выпуск наконец готов.

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

Поговорим про степень контроля и как её измерять, проблемные признаки больших команд, а еще, внезапно, про чеклисты) ✅

Apple
Google
Spotify
Яндекс
Castbox
Overcast
Web

18 сентября (в субботу) буду рассказывать про агрегаты на конфе Code/R. Присоединяйтесь, готовьте вопросы и подключайтесь к обсуждению онлайн. https://code-r.ru/

Выложил доклад Олега (@olegfedoseev) с прошлого митапа https://www.youtube.com/watch?v=i_23hgG3x8w Лайк-шер)

Не ивент штормингом единым)

Как отмечают многие эксперты, все эти агрегаты и прочие тактические паттерны вторичны для true-DDD. А первично общение с бизнесом, понимание истинной природы запроса. Именно это позволяет создавать фичи максимально заточенные под потребность. Разработчики, которые практикуют DDD обязаны выходить за пределы техники и примерять себе роль продакта.

Какие инструменты мы можем использовать?

1. Самый простой и многим привычный инструмент – Юзер стори. Не забывайте, что это не просто формальное предложение на карточке, а как и много в аджайл повод пообщаться.
2. Event Storming – хорошо знакомый ДДД-практикам воркшоп. Если вы не знакомы, то здесь много полезных ссылок.
3. Jobs To Be Done (aka JTBD).
Далее цитата из статьи:
Продукт, который вы создаете, решает проблему пользователя — «выполняет работу». Пользователи покупают, то есть «нанимают на работу» ваш продукт, чтобы он сделал свою работу — и сделал жизнь пользователя немного счастливее.
4. Decantation Tank.
Этот канвас помогает сконцентрироваться на предназначении продукта, проблемах пользователей, метриках и идеях.

5. Fit for purpose (aka F4P)

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

Это неполный список! В мире продактов есть еще пачка различных техник, фреймворков и канвасов. Делитесь в комментариях как часто вы входите в зону продакт-менеджмента и какими инструментами при этом пользуетесь.

У подхода аппенд-онли (например в event driven architecture) есть пачка бенефитов. Но также есть и проблема с удалением сенсетив информации, например для соблюдения права на забвения.
Я рекомендую подход из статьи не только для аппенд онли подхода – у всех у нас (надеюсь🥶) есть бэкапы. И удалять записи из пачки бэкапов, которые хранятся в каком-нибудь glacier – то еще удовольствие.

P.S. Тут разобран достаточно простой случай, когда данные однозначно соответствуют одному ключу. Бывает не столь однозначное соответствие, но это уже совсем другая история)