Создание архитектуры приложения

Создание архитектуры приложения — это проектирование внутреннего устройства продукта. Архитектура описывает, из каких частей состоит система и как они связаны. В статье разобраны слои, шаблоны, базы данных и этапы работы над архитектурой.

Содержание

Материал разбит на смысловые блоки. Каждый пункт отвечает на конкретный вопрос.

•     Что такое архитектура приложения и почему она важна
•     Что такое архитектура ПО и для чего она нужна
•     Зачем нужно проектировать приложение
•     Из чего состоит архитектура приложения
•     Слои приложения: интерфейс, логика, данные
•     Клиент-серверная архитектура
•     Монолит и микросервисная архитектура
•     Архитектура мобильного приложения
•     Архитектура веб приложения
•     Шаблоны MVC, MVP и MVVM
•     Принципы SOLID и признаки хорошей архитектуры
•     С чего начать: сбор требований о продукте
•     Выбор стека технологий
•     Определение ключевых сущностей сервиса
•     Базы данных и хранение
•     Взаимодействие через API
•     Безопасность и обработка данных
•     Масштабирование и развитие системы
•     Проверяем полноценность архитектуры
•     Кто разрабатывает архитектуру
•     Частые ошибки при проектировании
•     Что дальше

Дальше каждый пункт разобран по порядку. Статья поможет понять, как построить архитектуру приложения.

Что такое архитектура приложения и почему она важна

Архитектура приложения — это схема внутреннего устройства продукта. Она показывает компоненты системы и связи между ними.

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

Хорошая архитектура даёт команде такие возможности:

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

Это фундамент, на котором стоит весь подход к разработке. Переделать его позже дорого и долго.

Важно! Архитектура — это решения, которые сложно изменить потом. Поэтому их принимают в начале проекта, а не в середине.

Что такое архитектура ПО и для чего она нужна

Архитектура программного обеспечения описывает устройство любой системы. Приложение — только частный случай.

Такое описание отвечает на вопрос, какие компоненты приложения существуют и как они общаются. Она фиксирует технические решения и ограничения. Документ становится общим языком команды.

Архитектура программного обеспечения нужна, чтобы:

•     разработчик понимал место своей задачи
•     компании было проще менять команду проекта
•     системы могли работать под нагрузкой
•     бизнес видел стоимость доработок заранее

Это не бюрократия, а инструмент экономии. Понимание структуры экономит месяцы работы.

Зачем нужно проектировать приложение

Проектирование идёт до написания кода. Оно отвечает на вопрос «как», когда уже понятно «что».

Без проектирования каждый разработчик решает задачи по-своему. Код становится несогласованным. Любое изменение задевает другие части системы.

Зачем разрабатывать архитектуру проекта:

1.       Понять требования бизнеса и пользователя.
2.       Выбрать подход и технологии под задачи.
3.       Разделить систему на компоненты.
4.       Описать взаимодействие между частями.

Такое описание экономит время всей команды. Разработчики двигаются в одном направлении.

Из чего состоит архитектура приложения

Архитектура приложения состоит из компонентов и связей между ними. Каждый компонент решает свою часть задачи.

Один компонент отвечает за интерфейс, другой за бизнес логику, третий за хранение. Между ними идут понятные вызовы. Такое разделение упрощает поддержку.

Типовые компоненты приложения:

•     слой пользовательского интерфейса и его элементов
•     слой бизнес-логики с правилами продукта
•     доступ к базе данных
•     внешние сервисы и интеграции

Компоненты можно менять по отдельности. Это главное преимущество продуманной схемы.

Слои приложения: интерфейс, логика, данные

Классический подход делит приложение на три слоя. Каждый слой знает только соседний.

Верхний слой показывает данные пользователя и принимает действия. Средний слой содержит логику и правила. Нижний работает с хранилищем.

Слои работают так:

•     интерфейс: экраны, кнопки, формы, HTML или UI-компоненты
•     логика: расчёты, проверки, сценарии использования
•     данные: базы, файлы, кеш
•     инфраструктура: логи, очереди сообщений, доступа к внешним системам

Разделение на слои — самый простой вариант старта. Он подходит большинству современных проектов.

Клиент-серверная архитектура

Клиент серверная архитектура делит приложение на две стороны. Клиент показывает интерфейс, сервер хранит данные.

Приложение на устройства отправляет запрос, сервер возвращает ответ. Логика может быть на любой стороне. Чаще важные проверки держат на сервере.

Такой подход даёт следующее:

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

Клиент-серверная схема лежит в основе почти всех продуктов. Её используют и мобильные, и веб-приложения.

Монолит и микросервисная архитектура

Монолит — это одно приложение с общим кодом. Микросервисная архитектура делит систему на независимые сервисы.

Монолит проще запустить и удобно поддерживать небольшой командой. Микросервисы дают гибкость крупному продукту. Выбор зависит от размера проекта.

Многие компании начинают с монолита. Микросервисная архитектура появляется, когда проект вырос.

Архитектура мобильного приложения

Схема мобильного приложения учитывает работу на устройстве. Ресурсы телефона ограничены, связь бывает нестабильной.

Приложение хранит часть данных локально. Оно синхронизируется с сервером при появлении сети. Логику разделяют на экраны и общие модули.

Архитектура мобильного продукта обычно включает:

•     слой экранов и пользовательского интерфейса
•     слой бизнес-логики приложения
•     локальное хранилище и кеш данных
•     модуль работы с API сервера

Такое устройство одинаково для приложений для Android и iOS. Отличается только реализация на конкретном языке, например Java или Kotlin.

Архитектура веб приложения

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

Фронтенд отвечает за интерфейс и отправляет запросы. Бэкенд обрабатывает логику и обращается к базе. Между ними работает API.

Веб-приложение обычно состоит из таких частей:

•     клиентская часть в браузере
•     серверная часть с бизнес-логикой
•     база данных для хранения
•     сервис файлов и статики

Веб и мобильный продукт часто используют один бэкенд. Это удобно и снижает стоимость поддержки.

Шаблоны MVC, MVP и MVVM

Шаблоны описывают, как разделить код внутри слоя. Они решают одну задачу разными способами.

MVC делит код на модель, представление и контроллер. MVP выносит логику в презентер. MVVM связывает данные и интерфейс через модель представления.

Шаблоны используют, чтобы:

•     отделить логику от отображения
•     упростить проверку кода тестами
•     разделить работу внутри команды
•     повторно использовать компоненты

Выбор шаблона зависит от платформы и привычек команды. Главное — придерживаться одного подхода во всём проекте.

Принципы SOLID и признаки хорошей архитектуры

SOLID — набор принципов проектирования кода. Они помогают держать систему в порядке.

Каждый класс должен решать одну задачу. Компоненты должны зависеть от абстракций, а не от деталей. Новые функции добавляются без переписывания старого кода.

Признаки хорошей архитектуры:

•     компоненты слабо связаны друг от друга
•     изменения в одном месте не ломают другие
•     логику легко покрыть тестами
•     новый разработчик разбирается за дни, а не месяцы

Эти признаки проверяют на ревью. Они показывают качество решений лучше любых схем.

С чего начать: сбор требований о продукте

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

Команда собирает функции продукта и ожидания бизнеса. Уточняет число пользователей и нагрузку. Фиксирует ограничения по срокам и бюджету.

На старте нужно узнать:

1.       Какие задачи решает продукт.
2.       Кто им пользуется и как часто.
3.       Какие данные хранятся и обрабатываются.
4.       Какие есть технические ограничения.

Ответы дают основу для решений. Без них архитектура строится на догадках.

Выбор стека технологий

Стек — это набор языков и инструментов проекта. Его выбирают под задачи, а не по моде.

Учитывают опыт команды и требования к нагрузке. Смотрят на поддержку технологии в будущем. Наши проекты чаще строятся на проверенных решениях.

При выборе стека важно оценить:

•     наличие специалистов на рынке
•     скорость разработки на этой платформе
•     стоимость инфраструктуры сервиса
•     возможность масштабирования в будущем

Первый набросок архитектуры делают сразу после выбора. Он показывает, как части системы связаны.

Определение ключевых сущностей сервиса

Сущности — это объекты, которыми оперирует продукт. Например, пользователь, заказ, товар, сообщение.

Для каждой сущности описывают поля и связи. Определяют, кто её создаёт и меняет. Так появляется модель данных.

Описание сущностей включает:

•     название и назначение объекта
•     поля и типы данных
•     связи с другими сущностями
•     правила доступа и изменения

Ясная модель упрощает работу с базой. Она же помогает обсуждать продукт с бизнесом.

Базы данных и хранение

База данных хранит состояние приложения. От её структуры зависит скорость работы.

Реляционные базы подходят для строгих связей. Документные удобны для гибких структур. Часто в одном проекте используют оба варианта.

При проектировании хранилища учитывают:

•     объём и рост данных со временем
•     частоту чтения и записи
•     требования к резервным копиям
•     скорость доступа к нужным записям

Ошибки в схеме базы дороже всего. Их исправление затрагивает весь проект.

Важно! Структура базы данных меняется сложнее всего. Продумайте её до того, как в систему попадут реальные записи.

Взаимодействие через API

API — способ общения частей системы. Через него клиент получает данные от сервера.

Каждый метод API описывает запрос и ответ. Формат фиксируют в документации. Так разные команды работают независимо друг от друга.

Хорошее API отвечает таким требованиям:

•     понятные названия методов
•     стабильный формат ответа
•     версии для обратной совместимости
•     описание ошибок и кодов ответа

Через API подключают и внешние сервисы. Например, оплату, карты или модели ИИ.

Безопасность и обработка данных

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

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

Базовые меры безопасности:

•     проверка прав доступа к каждому методу
•     шифрование чувствительных данных
•     журналы действий пользователя
•     согласие на обработку персональных данных

Политика конфиденциальности описывает, как компания работает с данными. Пользователь даёт согласие на обработку при регистрации.

Масштабирование и развитие системы

Масштабирование — способность системы выдержать рост. Его закладывают заранее.

Нагрузку распределяют между серверами. Тяжёлые операции выносят в очереди. Кеш снижает число обращений к базе.

Приёмы масштабирования:

•     горизонтальное добавление серверов
•     кеширование частых запросов
•     очереди для фоновых задач
•     разделение тяжёлых сервисов

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

Проверяем полноценность архитектуры

Готовую архитектуру приложения проверяют до старта разработки. Это дешевле, чем находить пробелы в коде.

Проверяют, все ли сценарии покрыты компонентами. Смотрят, что происходит при сбое. Оценивают, как система переживёт рост.

Чек-лист проверки:

1.       Каждый сценарий проходит через описанные компоненты.
2.       Понятно, где хранятся все данные.
3.       Описано поведение при ошибках и отказах.
4.       Ясно, как добавить новые функции.

Такой разбор занимает несколько часов. Он экономит недели переделок.

Кто разрабатывает архитектуру

Схему разрабатывает архитектор или ведущий разработчик. В небольших командах это делает тимлид.

Архитектор общается с бизнесом и командой. Он переводит требования в технические решения. Затем следит, чтобы код им соответствовал.

Чтобы стать архитектором, обычно нужно:

•     несколько лет опыта разработки
•     понимание разных подходов и шаблонов
•     умение объяснять решения бизнесу
•     практика на реальных проектах и профильные курсы

Это следующий шаг после сильного разработчика. Путь занимает несколько лет работы в IT.

Частые ошибки при проектировании

Ошибки в устройстве приложения проявляются не сразу. Обычно они всплывают при росте продукта.

Одни команды усложняют схему без нужды. Другие вообще не проектируют и пишут код сразу. Оба варианта дорого обходятся.

Частые ошибки:

•     микросервисы в маленьком проекте
•     вся логика в одном большом модуле
•     нет описания архитектуры на бумаге
•     игнорирование требований к нагрузке

Баланс важнее моды на технологии. Схема должна соответствовать размеру проекта.

Что дальше

После проектирования начинается разработка. Схема становится рабочим документом.

Команда пишет код по описанной схеме. Изменения вносят осознанно и фиксируют. Раз в несколько месяцев схему пересматривают.

Дальнейшие шаги проекта:

•     разработка по утверждённой схеме
•     регулярное ревью технических решений
•     обновление документации при изменениях
•     развитие системы под новые задачи

Архитектура приложения живёт вместе с продуктом. Её поддерживают так же, как код.

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