В архитектуре нет бесплатных решений. Монолит и микросервисы, слоистая архитектура и DDD, высокое и низкое покрытие тестами — любой вариант даёт одни свойства и заставляет платить другими.
Поэтому вопрос «какая архитектура правильная?» мало полезен. Гораздо важнее понять, какие свойства нужны в конкретной ситуации и какую цену команда готова за них заплатить.
Начните с критериев
Без критериев анализ быстро превращается в обмен вкусовщиной. До сравнения вариантов полезно зафиксировать:
- какую проблему мы решаем;
- какие свойства системы для нас важны;
- какие ограничения есть у команды и бизнеса;
- какие допущения мы делаем;
- как поймём, что решение сработало.
После этого можно сравнивать варианты. Методика тут вторична: иногда хватает списка плюсов и минусов. Мне удобен SWOT, потому что он вынуждает отдельно подумать о возможностях и рисках.
Как использовать SWOT
- Strengths — сильные стороны варианта.
- Weaknesses — слабые стороны и прямые издержки.
- Opportunities — какие возможности для продукта и бизнеса открывает решение.
- Threats — какие риски создаёт решение.
Например, при выделении сервиса из монолита в сильные стороны могут попасть независимое масштабирование и возможность отдать компонент отдельной команде. В слабые — распределённые транзакции и усложнение эксплуатации. В возможности — подготовка к росту нагрузки. В риски — нехватка опыта у команды, рост сроков и числа отказов.
Сам SWOT не принимает решение. Он лишь помогает явно записать цену каждого варианта. Дальше нужно вернуться к исходным критериям и выбрать тот набор компромиссов, который подходит ситуации.