Архітектура мобільного застосунку: значення, типи та складові

Фінальний успіх мобільного застосунку залежить від того, наскільки добре були продумані всі деталі під час його розробки. Безумовно, коректний вибір маркетингової стратегії також важливий, проте він не змусить аудиторію використовувати ваше рішення на постійній основі – зокрема, якщо воно спочатку було сконструйовано неправильно та недружньо з погляду користувацького досвіду. У подоланні всіх цих перешкод архітектура відіграє не останню роль. Нижче ми розповімо докладніше про те, як влаштована архітектура мобільного додатку, як вона працює, і з яких ключових компонентів вона складається.

Що таке архітектура мобільного додатку?

Архітектура мобільного застосунку – це низка рішень та дій, що дозволяють організувати коректну роботу програми. До неї входять як інтерфейси, так і структурні елементи, бази даних, стилі та інші компоненти. 

Правильно побудована архітектура застосунку має відповідати наступним критеріям:

• бути ефективною та виконувати свої функції, незалежно від навантаження на сервер;

• залишатися гнучкою та мати можливість розширення новим функціоналом;

• легко піддаватися тестуванню – це підвищує надійність та зменшує час на перевірку та впровадження нових функцій;

• бути зрозумілою та структурованою – це спрощує розширення проєктної команди через залучення нових спеціалістів.

Розробкою архітектури займається окремий фахівець – системний архітектор. Він/вона визначає бізнес-логіку програми, спираючись на вимоги, стандарти та перспективи оптимізації/масштабування. Також цей спеціаліст відповідає за вибір стеку технологій для розробки, створює прототипи, веде документацію та координує розробників у процесі роботи над проєктом.

Важливість, необхідність та роль архітектури мобільного додатка

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

Типи архітектур мобільного додатку

Можна виділити чотири найпопулярніші типи архітектури мобільного додатка. Вибір на користь конкретного типу робиться виходячи з проєктних вимог, джерел та ресурсів для отримання даних, а також перспектив масштабування.

• MVC (Model-View-Controller)

Реалізація архітектури MVC полягає в розбитті програмного коду на три компонента: модель (відповідає за дані, що використовуються програмою), представлення (описує зовнішній вигляд програми) і контролер (контролює те, як функціонуватиме програма). Завдяки такому поділу, члени проєктної команди можуть працювати над кожним із цих трьох компонентів незалежно один від одного, тим самим, скорочуючи час розробки та спрощуючи налагодження, тестування та оптимізацію продукту.

• MVP (Model-View-Presenter)

Архітектура MVP – це одна з інтерпретацій MVC, в якій замість Controller використовується Presenter, менш залежний від Model і виконуючий роль функціонального прошарку. Це накладає певні особливості на специфіку взаємодії між Model і View – тепер це відбувається не напряму, а через посередника Presenter. Такий підхід має сенс у випадках, коли зв'язування даних реалізувати неможливо.

• MVVM (Model-View-ViewModel)

Паттерн MVVM також поділяє додаток на три окремі частини: Model (це дані, процеси з їх участю, запити тощо), View (зовнішній вигляд програми) і ViewModel (своєрідний прошарок між View і Model, який дозволяє не використовувати інтерфейси представлення (View) при зв'язуванні даних). Як і попередні два типи, цей значно спрощує тестування, обслуговування та подальше доопрацювання програмного забезпечення, дозволяючи проєктним командам розділяти між собою окремі задачі та виконувати їх синхронно.

• Clean Architecture

Це ще один популяний тип архітектури, який передбачає поділ програми на рівень представлення, рівень програми, рівень домену і рівень інфраструктури. При цьому розробники повинні дотримуватись низки принципів, таких, як збереження незалежності від фреймворків, забезпечення простоти тестування, незалежність від UI, незалежність від баз даних, а також незалежність від будь-яких зовнішніх ресурсів та інструментів. Окрім цього, згідно з Clean Architechture, модулі на більш високих рівнях не повинні залежати від тих, що розташовані рівнями нижче; при цьому, залежності між модулями реалізуються через абстракції, які, у свою чергу, не повинні залежати від деталей (зворотна залежність дозволена). Таким чином, зміни, які вносяться в модулі на низьких рівнях, не відбиваються на модулях вищих рівнів.

Складові архітектури мобільних додатків 

З точки зору кінцевого користувача, робота мобільного додатка полягає у взаємодії з програмним інтерфейсом. Насправді, мобільні додатки мають більше компонентів, які формують їхню архітектуру. Давайте розглянемо складові архітектури мобільного додатку детальніше.

Фронтенд (сторона клієнта)

Фронтенд – це візуальна частина мобільного застосунку, з якою користувач взаємодіє напряму. Сюди можна віднести дизайн програми, реалізовану в ньому інтерактивність та представлення даних. Виконуючи будь-які дії з цими компонентами, користувач отримує певну реакцію програми, що відображається візуально (іноді додаються звукові ефекти). З технічної точки зору, в цей момент здійснюється запит на серверну частину програми, де відбувається його обробка та генерується результат.

На відміну від дизайну, фронтенд-розробка включає не тільки візуалізацію інтерфейсу користувача (тобто, кнопок, плеєрів, картинок, іконок тощо), але і наповнення його функціональними можливостями (наприклад, кнопка для запуску меню відкриває це меню, кнопка для виходу виходить із додатка і т.д.).

Бекенд (Серверна сторона)

Бекендом називається серверна частина мобільного додатка, яка бере безпосередню участь у обробці даних, отриманих або через кінцевого користувача, або опосередковано, через запит на стороні фронтенда до бази даних додатка. Це все те, що приховано від очей кінцевих користувачів мобільних програм і що відповідає за надання їм певних реакцій програми на їх конкретні дії.

З погляду реалізації, бекенд передбачає написання серверних скриптів і роботу з серверними технологіями. На їх основі здійснюються певні сценарії для обміну даними, підключаються правильні системи та інструменти для управління та зберігання інформації, а також забезпечується загальна продуктивність мобільного додатка та виключаються збої у його роботі.

База даних

База даних – це впорядкований набір електронних даних із єдиною структурою. Використання баз даних у ролі компонентів архітектури мобільних додатків дозволяє знизити швидкість завантаження їхніх сторінок та підвищити загальний рівень безпеки та стабільності системи. Також такий підхід спрощує додавання нового контенту, оскільки за необхідності, з базою даних це стає можливим без участі розробників (адміністратори, які мають відповідні права доступу, можуть зробити це самостійно).

Варто зазначити, що бази даних дозволяють створювати нові типи даних, використовуючи ті, що вже існують, а також спрощують та зменшують обсяг роботи для розробників, які використовують об'єктно-орієнтований підхід: завдяки можливості виділяти загальні властивості та формувати на їх основі класи, розробники отримують можливість уникати надмірної кількості запитів всередині системи.

Аутентифікація та безпека

Аутентифікація визначає те, як відбувається перевірка особи користувача, який хоче увійти до системи. Невід'ємним атрибутом аутентифікації вважається обліковий запис користувача, що вимагає введення логіна, пароля та, опціонально, деяких інших даних. Нині популярна так звана двофакторна автентифікація, яка використовує або нативні можливості мобільних платформ, такі як отримання SMS та прийняття дзвінків, або сторонні сервіси, подібні до електронної пошти, для генерації одноразових кодів. 

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

Проєктування архітектури мобільного додатку

Спробуймо з'ясувати, які етапи передбачає процес проєктування архітектури мобільного додатку.

Визначення вимог

Перш, ніж проєктувати мобільний додаток і будувати його архітектуру, мобільним розробникам потрібно зрозуміти, якими є його цілі. Для цього команда розробки обговорює проєкт з його власниками та іншими зацікавленими особами, щоб з'ясувати, які саме задачі він повинен виконувати, які перспективи його розвитку вони розглядають у майбутньому, і яким чином буде реалізована його монетизація. Також визначаються мобільні платформи, на яких розгортатиметься додаток, та узгоджується його функціонал та джерела отримання даних.

Зрештою, таке детальне "інтерв'ю" зі стейкхолдерами допомагає проєктній команді сформулювати список специфікацій до додатку та його документацію, які, у свою чергу, можна сприймати як відправну точку та фундамент для побудови правильної архітектури.

Вибір підходу до архітектури

На цьому етапі формується загальна ідея, де визначаються основні можливості майбутнього програмного рішення. Ці інсайти допомагають системним архітекторам усвідомити, яким саме чином реалізовуватиметься задуманий функціонал з технічної точки зору, і який для цього підійде стек технологій найкраще.

Вище ми вже згадали про чотири найпоширеніші типи (патерни) розробки мобільних додатків – це MVC, MVP, MVVM та Clean Architecture – як ви можете пам'ятати, кожен з них вибирається в залежності від можливостей прив'язки даних та їх поділу. Власне, цей етап дозволяє проєктним командам отримати достатньо інформації від замовника, щоб зробити вибір на користь найбільш коректного варіанту, який забезпечив би подальшу масштабованість проєкту і прискорив роботу над його версіями.

Розробка компонентної структури

У попередньому розділі ми описали чотири ключові складові архітектури мобільного додатку: це фронтенд, бекенд, бази даних та рішення безпеки. У той же час, будь-який з наведених вище патернів (MVC, MVP, MVVM і Clean Architecture) може бути реалізований як із задіянням кожного (або декількох) з них, так і для окремого компонента окремо – все залежить від обраного технологічного стеку та бізнес-логіки застосунку. Також важливо відмітити, що в одному додатку може бути реалізований лише один патерн.

Така гнучкість дозволяє розробникам реалізовувати навіть найскладніші користувальницькі сценарії, зазначені замовником, не ускладнюючи при цьому програмну структуру програми і, тим самим, не уповільнюючи процес її тестування та оптимізації.

Планування взаємодії між компонентами

Правильна архітектура мобільного додатку передбачає те, що цей додаток розуміє, яким саме чином йому потрібно діяти за конкретних користувацьких сценаріїв (тобто, фактично, виключаються ситуації, коли певна дія користувача в рамках інтерфейсу призводить до зависання системи або видачі повідомлення про системну помилку). На етапі планування це відображається у визначенні способів взаємодії та зв'язків між її окремими компонентами, про які ми неодноразово згадували раніше. 

Більше того, відзначимо, що цей етап допомагає виключити зайві кроки на шляху передачі даних з фронтенду до бекенд і назад. Таким чином, системні архітектори можуть вже на ранніх етапах розробки мобільного додатка забезпечити його високу продуктивність та інтерактивність.

Забезпечення безпеки

З точки зору планування архітектури програми, її безпека полягає в передбаченні системними архітекторами способів аутентифікації/авторизації кінцевих користувачів, а також скорочення числа компонентів, що використовують приватні дані користувача.

Крім того, обираються компоненти та визначаються процеси, які вимагають шифрування даних; також передбачаються засоби та інструменти, які відповідають за їх фільтрацію та приведення до єдиного формату.

Нарешті, системні архітектори повинні забезпечити відсутність у створюваній ними архітектурі єдиної точки відмови – тобто, вузла системи, при збої в якому весь мобільний додаток втрачає свою працездатність. Це підвищує якість користувальницького досвіду і виключає втрату проміжних даних, оскільки при виникненні збоїв користувачам не доведеться виходити з додатку і запускати його заново.

Тестування архітектури

Хоча формальне визначення процесу тестування архітектури мобільного додатка нічим не відрізняється від того, що ми звикли розуміти під поширеним терміном “Quality Assurance” (відповідність проєкту заздалегідь визначеним специфікаціям та критеріям якості), практична його реалізація потребує інших методів та підходів – тут немає жодного покриття програмного коду тест-кейсами і баг-репортів. Це тестування здійснюється ще до етапу програмування та націлене, перш за все, на виявлення можливих проблем та перспектив оптимізації/масштабування програми.

Зокрема, архітектурне тестування включає виявлення проблем, які можуть негативно позначитися на швидкості розробки та чистоті програмного коду. Також тестування архітектури допомагає розробникам відкрити ключові напрями для покращення продуктивності та надійності створюваного рішення.

Оптимізація продуктивності і ресурсів

Для оптимізації продуктивності мобільного додатка через його архітектуру зазвичай використовуються такі методи та підходи:

• рев'ю, при якому системні архітектори аналізують попередньо створену архітектуру мобільного додатка та зіставляють її з визначеними вимогами та стандартами, описаними в документації;

• аналіз обраної моделі, який полягає у використанні спеціалізованих аналітичних інструментів, що допомагають визначити потенційні проблеми та перспективи масштабування згідно зі списком специфікацій до проєкту;

• розробка прототипів, що передбачає створення відразу декількох прототипів, заснованих на різних архітектурних патернах, і націлених збирання зворотнього зв'язку із боку решти проєктної команди та кінцевих користувачів;

• сценарне тестування, що включає розробку стандартних сценаріїв користувача з позначенням задіяних в них архітектурних компонентів і зв'язків між ними.

Виконані поодинці або в сукупності, ці прийоми допомагають досягти найкращої архітектури для конкретного проєкту.

Масштабування архітектури

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

Так, якщо ми говоримо про масштабування функціоналу, він зазвичай реалізується через підключення нових API. Якщо ж розглядати підвищення продуктивності, воно може бути досягнуто декількома способами: перенесенням мобільного додатка на хмарні сервери (з локальних серверів) або підключенням додатка до CDN – тут все залежить від конкретних завдань, які були покладені на програму.

Розробіть власний мобільний додаток разом з WEZOM

Якщо ви хочете створити мобільний додаток – наприклад, для фітнесу та тренувань, – звертайтесь до нас. Наші фахівці проаналізують вашу ідею, створять чіткий план її реалізації та розпочнуть роботу. В результаті, за лічені місяці ви отримаєте готовий продукт, повністю заточений під потреби та цілі його аудиторії та наділений підвищеною конкурентоспроможністю. Напишіть нам, зателефонуйте чи просто приходьте до нас в офіс – ми будемо раді проконсультувати вас з будь-яких питань, пов'язаних із мобільною розробкою.

Висновок

Як бачимо, архітектура мобільного додатку – це невід'ємна його частина, яка здатна як подовжити його життєвий цикл і зробити більш стійким до подальших модернізацій та оптимізацій, так і мати зворотний ефект. Зрештою, правильно обрана архітектура забезпечує узгодженість мобільного додатка з бізнес-цілями його власників, оскільки саме вона відповідає за швидке та просте внесення змін, масштабування та розширення функціоналу. Якщо ви хочете, щоб ваша команда розробки відповідально поставилася до створення архітектури для вашого проєкту, зв'яжіться з нами просто зараз.

FAQ

Що таке архітектура мобільного додатку?

Архітектура мобільного додатку – це підхід до організації та структурування програмного коду, з якого складається цей додаток. Правильний вибір архітектури спрощує як процес створення додатку, так і його подальше доопрацювання та підтримку.

З чого складається архітектура мобільного додатку?

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