Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.
И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же это собственно такое?
Ниже я привёл несколько картинок которые описывают ту или иную архитектуру
И как мы видим все эти картинки абсолютно разные. Так что же всё таки такое архитектура?
Архитектура программного обеспечения относится к фундаментальным структурам программной системы и дисциплине создания таких структур и систем. Каждая структура включает элементы программного обеспечения, отношения между ними, а также свойства как элементов, так и отношений. Архитектура программной системы - это метафора, аналогичная архитектуре здания. Он функционирует как план для системы и проекта разработки, в котором излагаются задачи, которые должны быть выполнены командами разработчиков.
Ну теперь когда мы разобрались с тем что такое архитектура, давайте разберемся, а зачем она собственно то нужна? И на самом деле ответ довольно простой и легко изобразить на следующей картинке.
Чем старше становится проект, тем больше у нас технического долга, даже если функциональность проекта не сильно меняется, то технический долг всё равно накапливается со временем и в какой то критический момент мы уже занимаемся тем, что пытаемся просто исправлять баги, а на новую функциональность времени попросту не хватает.
Ну хорошо, мы разобрались что такое архитектура и зачем она собственно нужна, но как же её собственно строить?
Первое что нужно понимать, это что мы вообще строим. Нужно понять что за проект мы делаем. Это кажется очевидным, но я часто видел в своей практике когда архитектор просто приходит и говорит что давайте сделаем микросервисы, не разобравшись в том, что мы делаем и вообще зачем мы это делаем.
Далее нам нужно понять, а зачем вообще заказчику понадобилась новая архитектура и почему мы должны её продумывать. Так же мы должны ответить на вопрос, а почему была выбрана именно текущая архитектура, и почему мы попали в ситуацию что заказчику нужно её поменять? Какие проблемы мы имеем с текущей архитектурой?
Ну и самое главное, мы должны собрать требования к нашей архитектуре, данные требования могут быть абсолютно разными, вот лишь некоторые из них:
fault tolerance (reliability) / отказоустойчивость (надёжность)
speed of development / скорость разработки
ease deployed / простота деплоя
scalability by the number of people in the project / масштабируемость по количеству человек в проекте
scalability in terms of requests per second / масштабируемость по количеству запросов в секунду
fast entry / exit to resolution / быстрый вход/выход в разработку
application deployment speed / скорость развертывания приложения
remove old code / избавиться от старого кода
complexity of adding new integrations / сложность новых интеграций
etc. / И т.д.
Например на одном из моих проектов важно была отказоустойчивость, но вот масштабируемость проекта, чтобы на нём могли находиться тысяча человек одновременно - не требовалось. Есть проекты в которых наоборот нужно чтобы миллионы пользователей могли одновременно сидеть, но если у одного из них случались проблемы(например сообщение не отправилось за 5 секунд), то это не критично, отправим его через 10 секунд.
К сожалению не существует золотой пули и идеально архитектуры которая подойдёт для всего, поэтому нам требуется как можно точнее собрать требования под конкретную архитектуру которую нам требуется разработать.
Такс, а теперь давайте ещё раз повторим вопросы на которые нам нужно ответить. Их всего 5:
Что мы делаем?
Почему мы имеем текущую архитектуру?
Почему нам нужна новая архитектура?
Какие проблемы мы имеем с текущей архитектурой?
Что хочет наш клиент от новой архитектуры?
Ну а теперь мы можем приступать к разработке нашей новой архитектуры.
Продолжение следует:
Часть 2: https://habr.com/ru/post/658151/