Разработка архитектуры для чайников. Часть 1

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 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:

  1. Что мы делаем?

  2. Почему мы имеем текущую архитектуру?

  3. Почему нам нужна новая архитектура?

  4. Какие проблемы мы имеем с текущей архитектурой?

  5. Что хочет наш клиент от новой архитектуры?

Ну а теперь мы можем приступать к разработке нашей новой архитектуры.

Продолжение следует:

Источник: https://habr.com/ru/post/658145/


Интересные статьи

Интересные статьи

Мы продолжаем серию публикаций адаптированного и дополненного перевода "Карманной книги по TypeScript". Другие части: Часть 1. Основы Часть 2. Типы на каждый день Часть...
Абсорбация (разложение) углеводов в организме человека с диабетом 1 типа. В данной статье анализируется абсорбация углеводов (на самом деле не только их, но так же и белк...
Подключение, отключение и обнаружение BLE сервисов. Читать далее
В предыдущих двух материалах (часть 1, часть 2) этой серии речь шла об общих вопросах работы epoll, и о том, как epoll получает уведомления о новых событиях от файловых дескрипторов, за к...
Всем привет. Я решил наконец-то разобраться, как работает интерпретатор Python. Для этого стал изучать одну статью-книгу и задумал заодно перевести её на русский язык. Дело в том, что перевод...