🏛Архитектура решения (Solution Architecture), в некотором смысле, является наиболее простой архитектурой. Простой, если её, например, сравнивать с архитектурой предприятия или системной архитектурой. При разработке архитектуры решений мы достаточно хорошо понимаем целевое состояние, в которое должны прийти. Мы примерно представляем, когда это случится, каким в этот момент времени должен быть набор функций решения, как будут выглядеть данные, какой набор технологий мы задействуем. Более того, мы неплохо понимает текущий набор технологий, приложений и данных из которого мы будем это целевое состояние создавать.

Сравним для примера этот уровень определенности с тем, с чем мы работает при разработке архитектуры системы. Пусть нам предстоит спроектировать систему, про которую мы знаем, что через пару месяцев должен полететь MVP, через полгода заказчику хочется покрыть некоторый базовый функционал, а через год от текущего момента времени выйти на окупаемость. Какую архитектуру нам рисовать? Ту, что сложится через год, полгода или в ближайшие пару месяцев? Они будут очень разные. Первая пара месяцев, быть может, предсказуема с точки зрения технологий. За этот срок вряд ли что-то изменится. Но на начальный момент времени предметная область (domain) окутаны густым туманом. Может быть что-то можно сказать про компонентный состав, т.е. мы выберем тот самый то ли стиль, то ли паттерн из книжек Форда и Ричардса. Через пару месяцев мы слегка начнем понимать домен. Через полгода может быть уже разуверимся в предсказанный заказчиком профиль нагрузки и начнем менять тот самый архитектурный стиль. К горизонту год что-то будет меняться в технологиях под нашей системой. В ходе всей истории мы регулярно будем узнавать много нового о реальных навыках команды разработчиков, а быть может и выбранном техстеке.

Вернемся к архитектуре решений. Там мы знали текущее состояние, целевое, возможно разбирались в предметной области и планировали в предположении неизменности технологий. Простая задачка для архитектора, не правда ли?