Репост из: Путь аналитика
Чем хороша доменная модель?
(и как её сделать быстро)
Всегда, когда прихожу в новый проект, сталкиваюсь с ситуацией:
- нужно быстро понять процесс,
- при этом он часто "размазан" между разными командами и разными сервисами
- список стейкхолдеров теряется за этой сложностью, легко кого-то пропустить
В итоге возникает задача:
1) понять наложение процесса на архитектуру и организационную структуру
2) часто еще нужен и слой модели данных, чтобы видеть где создаются и модифицируется ключевые объекты
Это даже звучит громоздко. При этом очень важно - иначе не организовать стейкхолдер менеджмент и легко потерять зависимость фичей и данных.
Как-то раз у меня был форс-мажор. Нужно было в короткие сроки разобрать большой домен компании. Ходила к разным экспертам за советом. Мне прямо говорили: «Так быстро не бывает. Нужно выбивать проект на месяцы».
А потом коллега (привет, Кеша Бодров!) показал Domain model из Domain Driven Design. Оказалось, можно просто сесть с командой и клеить стикеры в Miro Bounded Context template : субдомены, процессы, ответственные, сервисы, ключевые объекты. Работа творческая и позитивная. На выходе — ландшафтная картина домена. Детализацию можно варьировать под свои задачи.
Но есть нюанс: если домен небольшой, достаточно собрать пару команд. А если вовлечено десяток команд? DDD предлагает проводить event storming — выездные семинары для всех причастных. Звучит круто, но организовать и фасилитировать такое — отдельный подвиг.
Я попробовала иначе: нашла нескольких ключевых экспертов и пошла по одному.
- С первым набросала черновик
-- Со вторым сверила и дополнила
--- С третьим уточнила
---- К четвёртому серьёзные изменения модели уже закончились.
-—- Тогда отправила модель в общие чаты команд на согласование — получила отдельные уточнения и достаточно быстро закрыла вопросы.
Получилась картинка, по которой реально видно процесс целиком, со всеми зависимостями и зонами ответственности. При этом она не громоздкая.
Оказалось, работает даже когда «нельзя собрать всех». Несколько хороших разговоров с правильными людьми - очень даже эффективно.
Чем могу порекомендовать доменную модель:
✅ Быстрый онбординг новых людей
✅ Выравнивание контекстов между командами
✅ Понимание, где какие данные создаются и изменяются
✅ Удобная навигация по проекту (кто за что отвечает, от кого зависит)
✅ Основа для планирования изменений — сразу видно, кого и что затронет
А как вы боретесь с информационным хаосом на старте проекта? Делитесь лайфхаками в комментариях 👇
(и как её сделать быстро)
Всегда, когда прихожу в новый проект, сталкиваюсь с ситуацией:
- нужно быстро понять процесс,
- при этом он часто "размазан" между разными командами и разными сервисами
- список стейкхолдеров теряется за этой сложностью, легко кого-то пропустить
В итоге возникает задача:
1) понять наложение процесса на архитектуру и организационную структуру
2) часто еще нужен и слой модели данных, чтобы видеть где создаются и модифицируется ключевые объекты
Это даже звучит громоздко. При этом очень важно - иначе не организовать стейкхолдер менеджмент и легко потерять зависимость фичей и данных.
Как-то раз у меня был форс-мажор. Нужно было в короткие сроки разобрать большой домен компании. Ходила к разным экспертам за советом. Мне прямо говорили: «Так быстро не бывает. Нужно выбивать проект на месяцы».
А потом коллега (привет, Кеша Бодров!) показал Domain model из Domain Driven Design. Оказалось, можно просто сесть с командой и клеить стикеры в Miro Bounded Context template : субдомены, процессы, ответственные, сервисы, ключевые объекты. Работа творческая и позитивная. На выходе — ландшафтная картина домена. Детализацию можно варьировать под свои задачи.
Но есть нюанс: если домен небольшой, достаточно собрать пару команд. А если вовлечено десяток команд? DDD предлагает проводить event storming — выездные семинары для всех причастных. Звучит круто, но организовать и фасилитировать такое — отдельный подвиг.
Я попробовала иначе: нашла нескольких ключевых экспертов и пошла по одному.
- С первым набросала черновик
-- Со вторым сверила и дополнила
--- С третьим уточнила
---- К четвёртому серьёзные изменения модели уже закончились.
-—- Тогда отправила модель в общие чаты команд на согласование — получила отдельные уточнения и достаточно быстро закрыла вопросы.
Получилась картинка, по которой реально видно процесс целиком, со всеми зависимостями и зонами ответственности. При этом она не громоздкая.
Оказалось, работает даже когда «нельзя собрать всех». Несколько хороших разговоров с правильными людьми - очень даже эффективно.
Чем могу порекомендовать доменную модель:
✅ Быстрый онбординг новых людей
✅ Выравнивание контекстов между командами
✅ Понимание, где какие данные создаются и изменяются
✅ Удобная навигация по проекту (кто за что отвечает, от кого зависит)
✅ Основа для планирования изменений — сразу видно, кого и что затронет
А как вы боретесь с информационным хаосом на старте проекта? Делитесь лайфхаками в комментариях 👇