...сложно не облажаться в будущем.

С Вами снова Владимир и меня все еще зовут девопс.

Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.

Сегодня делюсь свежеобретенным представлением о создании архитектуры нового проекта или реконфигурации нового.

Введение

В идеальном мире есть solution architect, business architect, infrastructure architect, тех-лид, тим-лид, ПМ, ПО и орда системных аналитиков. Однако если их нет, это не повод отчаиваться больше, чем на полтора часа.

Заранее оговорюсь, я не solution architect и все изложенное – это путь самурая без меча, но с мечом

Кажется, что проектировщиком системы должен быть один человек (вопреки всяким аджайлам), ибо Java-разработчик хочет ведра RAM, devops  – энтерпрайзные облака с кубами и бд as service, иб – перерезанный сетевой кабель, а стекхолдеры седеют от таких "хотелок" и судорожно хватаются за сердце кошелек.

Стартуем, как правило, от бизнес-потребности – другими словами, задаемся вопросами: что бизнес хочет сделать и какую задачу решить?

Бизнес-потребность приезжает в таком виде:

• Бизнес хочет печь пирожки. Пока для себя, потом, может быть, и на продажу.

• Бизнес хочет печь пирожки с разной начинкой и возможность ее поменять.

• Бизнес хочет попробовать пирожки в небольшом объеме. И только потом строить пирожковый завод.

• Бизнес хочет что-то еще, но не совсем понимает что.

• Бизнес надеется на нашу экспертизу, мы ж не первый день "кухарим".

• Бизнес не знает, сколько будет выпекать, надеется выйти на тысячу в секунду. Но не сразу.

Попробуем разобраться в этих запросах и декомпозировать разработку архитектуры.

LVL 1. Что делать?

Итак, попробуем написать ОАР (общее архитектурное решение) для пирожков.

Следует выяснить, как выглядит конечный продукт, где он существует и его опции.
Фактически имеются две сущности – пирожок и место, где его сделают, то есть кухня.
Опции пирожка – тесто и начинка, опции кухни – расположение.

Определив базовые понятия, можем переходить к процессам, которые должны обеспечить доставку пирожка в магазин.

LVL 2. Как делать?

Разбор, какие логические потоки и опции нам нужны для "success backing".

Где и как собирается пирожок (варианты со скриптом "мешок с костями" отметаем сразу) и как, собственно, его испечь. Проще говоря, кто будет выполнять действия, отмеченные в предыдущем пункте.

Имеются три сущности: заготовка пирожка, кухня и пирожок.

Создается описание, какие функции выполняют сущности для реализации бизнес-запроса.

Желательно-обязательно заранее заложить возможность масштабирования. Благо, век "избыточных технологий" уходит. Очевидно, что на первых порах будет выпекаться десяток одинаковых пирожков в час, но предусматривается возможность, что их будет тысяча в секунду и с разным составом.

LVL 3. Где делать?

Девопс-мякотка. Люблю это дело, даже сейчас слюнки потекли. Самое сложное на этом этапе – удержаться. Заранее можно предсказать рассчитать нагрузку на инфраструктуру на определенном этапе, от этого и отталкиваемся. Понятно, что для 10 пирожков в час достаточно одной духовки, при 50 пирожках в час можно докупить еще две духовки, но на 100 и более – стоит задумываться о промышленном решении.

Описание физической структуры с потоками данных и техническими решениями.

Следует разделять "надо" от "хочется". На этапе подготовки MVP, т.е. пирожка-пробника, нет необходимости строить завод, однако технология приготовления пирожка должна предусматривать возможность поставить все итерации на конвейерный процесс.
С возможностью дополнения выполняющихся потоков и процессов, а не изменения "рецептуры". Конечно, если такой вариант есть.

Имея понимание, сколько, где и каких мощностей необходимо, можно планировать бюджет.

LVL 4. Поддержка

Диверсификация и предупреждение рисков.

В нашей ситуации нужны запасы теста и начинки, обслуживание духовки (в идеале – подменный вариант), пожарная сигнализация, свой человек в санэпиднадзоре и понимание, что делать, если вместо пирожков с вишневым вареньем получаются пирожки с отечественным кинематографом.

Не стоит забывать про процесс кормления пирожками тестовой группы манекенов.
Так же ввиду того, что все, что до стадии "Пирожок", не должно общаться с пирожковыми пользователями – нужно повесить табличку "посто-ронним В!" на кухню и внутренние помещения, а в магазине открываем дверь с баннером "Добро пожаловать!".

Итого

Методологий создания архитектуры ПО – масса. Изучение оных, как и детальный разбор архитектуры с акцентами на быстродействие, api, ui\ux и прочие тонкости – предмет работы отдельного специалиста и не одного. Да и сам процесс весьма сложный и требует высокоуровневого знания большого стека технологий.

Описанный же подход позволяет декомпозировать общий бизнес-запрос и предупредить потенциальные проблемы в разработке как tech-flow, так и business flow, пользуясь логикой и читая в гугле best practice по решению конкретной локальной задачи.