Я довольно часто вижу один и тот же сценарий: Обсуждаем новую фичу и уже через десять минут разговор уезжает в ретраи, таймауты и форматы контрактов, хотя мы еще не договорились, что вообще должна делать система. Или наоборот: все красиво на уровне идей, но при первом же вопросе «а кто за это отвечает?» модель разваливается. Со временем я поняла, что почти все такие проблемы упираются  в два базовых инструмента мышления: абстракцию и декомпозицию. Если их путать или использовать по отдельности, проект начинает трещать по швам. Проектирование ПО часто сводят к декомпозиции: большую задачу разбили на маленькие и пошли реализовывать. На самом деле у нас есть две независимые оси: Ось 1. Абстракция (вверх-вниз) Абстракция отвечает за уровень мышления. 🔺Вверх - говорим что делает система, не вдаваясь в детали. 🔻Вниз - раскрываем как именно это реализовано. Пример с оплатой: Бизнес-уровень: «Пользователь оплачивает заказ картой». Сервисный уровень: processPayment(orderId, cardToken). Интеграции: конкретный платежный шлюз и его API. Инфраструктура: HTTP, таймауты, ретраи. Типичная ошибка: обсуждать таймауты банка в бизнес-сценарии. Задача аналитика - держаться на нужном уровне и спускаться ниже только ради ограничений. Ось 2. Декомпозиция (вширь) Декомпозиция отвечает за разделение ответственности на одном уровне. 🔹На бизнес-уровне: доменные сущности и правила, сервисы обработки платежей и возвратов, внешние интерфейсы (платежи, уведомления). 🔹На уровне интеграций: разные шлюзы, реализующие один контракт, разные каналы уведомлений. 🔹Важно: мы делим не «как получится», а по архитектурным ролям. Как это выглядит в работе аналитика 1. Формулируем потребность на высоком уровне: «Нужен возврат средств». 2. Декомпозируем ее на этом же уровне: типы возвратов, сценарии, ограничения. 3. Фиксируем абстракции: сущность Возврат, интерфейс RefundProcessor. 4. Спускаемся ниже: какие сервисы и интеграции нужны. 5. Поднимаем ограничения обратно вверх: лимиты шлюзов становятся бизнес-правилами.