DDDevotion – Telegram
DDDevotion
4.42K subscribers
65 photos
7 files
273 links
All about Domain-Driven Design
FB - https://www.facebook.com/groups/dddevotion/
Youtube - https://www.youtube.com/c/dddevotion
По вопросам сотрудничества @gradea
Download Telegram
Ник Тьюн продолжает привносить новые инструменты в мир разработки и 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). Он расскажет про подход, который позволяет собирать документацию на основании программной модели. Используя этот подход вы увидите, как можно определить дефекты трансляции ментальной модели в программную и какой дополнительный профит мы можем из этого получить.
Наше сообщество поддерживает компания JetBrains. У меня есть купон на одну из их IDE. Отдам за лучший вопрос! Жду ваших здесь https://app.sli.do/event/3xzwxrro

До встречи на митапе!
DDDevotion pinned «Ссылка на трансляцию https://www.youtube.com/watch?v=5Adgq-4KJoo»
Друзья, все ссылки, презентации и код будут доступны. Выложу здесь завтра-послезавтра. Спасибо, что были с нами. До новых встреч)
Кстати, самый заплюсованный вопрос был от Сергея про будущее ДДД и без ДДД. Сергей, дай знать в комментах.
«Когда метрика превращается в цель, она перестает быть хорошей метрикой». Закона Гудхарта.

Оказывается умные люди полвека назад сформулировали проблему метрик. Что это значит? Если у вас есть метрики по коду и вы должны во что бы то ни стало в нее попасть, то жди проблем. Особенно, если у разработчиков будет зависеть от этих KPI зарплата.
Привет! Нас не было три недели (а никто даже и не спросил почему 😒), но новый выпуск наконец готов.

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

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

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

Как отмечают многие эксперты, все эти агрегаты и прочие тактические паттерны вторичны для 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. Тут разобран достаточно простой случай, когда данные однозначно соответствуют одному ключу. Бывает не столь однозначное соответствие, но это уже совсем другая история)
Александр Поломодов запостил обзор книги Чистая Архитектура. Книга и термин, введенный Бобом Мартином, очень популярны в индустрии, но книга не только и не столько про привычную луковичку, но и про принципы правильной архитектуры и даже про архитектуру как таковую. Если не читали – рекомендую к ознакомлению.

https://apolomodov.medium.com/clean-architecture-review-part-1-f4784cd43e29

https://apolomodov.medium.com/clean-architecture-review-part-2-dd1fe295b523

Цикл обзоров продолжается, следите за обновлениями.