Top-Down vs. Bottom-Up подходы в разработке

Этот материал объясняет концепции Top-Down и Bottom-Up — с примерами вопросов для проверки знаний, ключевыми компонентами и тегами.

Суть в двух словах

• Top-Down начинается с бизнес-целей и пошагово разбивается на подзадачи и интерфейсы.
• Bottom-Up стартует с готовых строительных блоков (библиотеки, фреймворки, сервисы) и собирает решение из них.

На практике часто работает встреча посередине.

Краткое техническое описание

Top-Down

• Сначала цели, контекст, сценарии использования
• Затем уточнение: подсистемы → компоненты → классы → операции
• Преимущество: четкие бизнес-границы, тесты естественно выводятся из требований

Bottom-Up

• Сначала переиспользование: библиотеки, SDKs, фреймворки, существующие системы
• Затем композиция и адаптация
• Преимущество: быстрый старт, меньше кода с нуля

Риски:

• Top-Down: технические ограничения становятся видны слишком поздно
• Bottom-Up: архитектура управляется технологией, затраты на интеграцию, привязка к поставщику

Важные пункты для повторения

• Четко разграничивать определения
• Минимизировать связанность, максимизировать внутреннюю связность
• Стабильно определять контракты между компонентами
• Трассируемость: требование → дизайн → тест
• Adapter и Anti-Corruption Layer для внешних компонентов
• Встреча посередине как реалистичная комбинация

Основные компоненты

1. Бизнес-цели и контекст
2. Разбиение на подсистемы
3. Контракты интерфейсов
4. Поиск существующих компонентов
5. Adapter/Фасад/Anti-Corruption Layer
6. Качественные показатели и архитектурные правила
7. SOLID/GRASP как руководство
8. Стратегия тестирования (интеграционные → unit)
9. Security, проверка зависимостей, лицензии
10. ADRs (версионирование решений)

Практический пример (платежная система)

Top-Down:
- Цель: безопасная авторизация платежей
- Сервисы: Payment Service, Order Service
- Интерфейсы: authorize(), cancel()

Bottom-Up:
- Есть: Payment SDK, HTTP-клиент, Event Bus
- Adapter инкапсулирует SDK
- Contract Tests против sandbox

Встреча посередине:
- определить бизнес-интерфейсы
- наполнить реальные адаптеры SDK

Плюсы и минусы

Top-Down

• Плюсы: чистая бизнес-структура, стабильные интерфейсы, хорошая тестируемость
• Минусы: медленный старт, технические риски проявляются поздно

Bottom-Up

• Плюсы: быстрые результаты, высокая переиспользуемость
• Минусы: риск архитектуры, управляемой технологией, затраты на интеграцию и привязка

Типичные вопросы для проверки (с кратким ответом)

1. Основное отличие? Top-Down разбивает от цели, Bottom-Up собирает из блоков.
2. Как это влияет на связанность и внутреннюю связность? Top-Down усиливает бизнес-связность; Bottom-Up может увеличить связанность.
3. Как это комбинировать правильно? Встреча посередине + адаптеры + ADRs.

Как учить этот материал

1. Для простой предметной области нарисовать оба подхода.
2. Определить интерфейсы как контракты.
3. Потренироваться писать Contract Tests для внешних компонентов.

Основные источники

1. https://refactoring.guru/design-patterns/adapter