part1-10.md

Дипломный проект, часть 1.

Детализация и чёткое прописывание бизнес-целей.

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

Бизнес цели я вижу следующие:

1. Так как мы в первую очередь компания которая продает спортивные товары, а не занимается благотвортельностью, то основная и самая главная бинес цель: к концу первого года работы приносить не менее 10% совокупного объема продаж по отношению ко всем остальным бизнес единицам компании (сайт, специализированные приложения).
2. Нам крайне важно сделать по-настоящему хорошее приложение, которым будут пользовваться как уже существующие клиенты компании, так и потенциально новые. Ввиду этого стоит ввести следующую бизнес цель: процент удержания не меньше половины от числа скачавших пользователей. Удержанным пользователем будет считаться тот который пользуется приложением хотя бы раз в каждый месяц на протяжении полу года после скачивания.
3. Войти в топ-5 приложений такой же тематике в App Store и Google Play по окончанию первого года работы.

Анализ и список функциональных требований.

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

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

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

As a/an	I want to	So that	Функциональное требование
Пользователь	Иметь возможность зареистрироваться	Получать персонализированную информацию.	Иметь возможность регистрации, хранения, логина пользователей в систему.
Пользователь	Хочу пользоваться приложением и в поездках тоже.	Чтоб оно не лагало там.	Реализовать доступность приложегния по всему земного шару.
Пользователь	Записывать свои тренировки. А после просматривать их.	Я мог наблюдать их после их окончания, анализировать и делиться ими.	Организовать хранение и вывод трекинговой информации.
Пользователь	Получать персональные предложения, скидки, акции, бонусы.	Мог делать покупки более приятно и адаптированно.	Реализовать бонусную систему, систему подсказок товаров и предложений.
Пользователь	Общаться с другими такими же клиентами.	Мог удовлетворять коммуникативные потребности не выходя из приложения.	Создать систему которая бы отвечала за хранение и передачу сообщений.
Пользователь	Получать сообщения сразу по мере их прихода в фоновом режиме.	Мог получать сообщения проще и быстрее.	Реализовать систему push уведомлений.
Пользователь	Делиться своими тренировками и публиковать в соц сетях.	Мог повышать свое ЧСВ.	Организовать систему шеринга информации: короткие ссылки, готовые сниппеты для инстаграмма и твиттера.
Пользователь	Мог оставлять комментарии под тренировками других людей.	Мог коммуницировать с другими участниками вне личных сообщений.	Сделать возможность оставлять комментарии под тренировками пользователей.
Пользователь	Мог делать покупки внутри приложения.	Не надо было выходить из приложения и мог тратить деньги не тратя силы/время.	Встроит внутрь интернет магазин с каталогом товаров и рекомендаций.
Пользователь	Мог отслеживать доставку	Был спокоен и видел движение своего заказа.	Реализовать отображение состояния заказа, рендер движения заказа в режиме реального мера по карте.
Пользователь	Мог платить внутри приложения	Была возможность платить картами, а не наличными курьеру.	Подключить добавление и оплату картами, подклюить Apple Pay, Google Pay.
Пользователь	Мог коммуницировать с тех поддержкой	Закрывать свои вопросы.	Встроить возможность написать в тех поддержку.
Пользователь	Мог заполнить свой профиль, указать вид спорта, поставить аватар.	Персонифицировать свой профиль, удовлетворить творческие порывы.	Дать возможность сохранить основную информацию о пользователе, среди которой вид спорта и марка/модели обарудования.
Пользователь	Подключать доп устройства: часы, браслеты.	Мог подключать свои уже существующие устройства и интегрировать/синхронизировать между собой.	Ознакомиться с API основных игроков рынка носимой электроники, сделать наше приложение совместимым.
Пользователь	Мог сранивать свои успехи с другими участниками и своими более старыми тренировками.	Отслеживать свой прогресс/дегресс.	Сохранение и агрегация тренировок пользователей. Отображение их на карте с треком маршрута, если тренировки предполагают уличную активность с перемещением в пространстве: бег, вело и тд. Введение систем участков.
Пользователь	Получать подсказки по тренировкам.	Мог прогрессировать а не деградировать.	Реализовать динамическую систему анализа данных тренировок пользователя, выдача релевантных рекомендаций.
Пользователь	Читать доп литературу/информацию/статьи/исследования не выходя из приложения.	Мог обогощать свои знания о выбранном виде спорта.	Создать систему по хранению и выводу постов.
Пользователь	Получать доставку на дом.	Мог не тратить время на получение товара и сделать шоппинг более приятным.	Интегрировать уже существующую в компании систему доставки.
Пользователь	Хочу видеть статистику по своим тренировкам в классном виде как в Apple Watch.	Мог наблюдать свой прогресс/дегресс.	Реализовать систему ачивок и удобоваримое отображение статистики.
Пользователь	Хочу быть уверенным что мои персональные данные в безопасности	Мог без оглядки пользоваться сервисом	Большое внимание удалить безопасности данных
Пользователь	Хочу мгновенно получать важные уведомления	Чтоб всегда быть в курсе всех событий	Сделать Messaging систему поддерживающую все основные интерфейсы (sms, email, push).
Маркетолог	Хочу удобно влиять на важные для меня параметры: SEO.	Мог управлять продвижением сайта и дополнять проект необходимыми мне данными.	Реализовать интеграцию с маркетинговыми средствами управления проектом.
Автор текстов	Удобно сохранять и редактировать авторский контент.	Мог работать более продуктивно.	Реализовать админку с поддержкоой удобного встроенного редактора постов, изображений. View/edit/create в рамках своей области.
Администратор	Хочу иметь возможность влиять на публикуемый контент в нашем приложении.	Мог вычищать неприемлимый противречащий законодательству контент.	Сделать админку с гибкой системой прав. Администратор может не только view, но еще и edit.
Специалист тех поддержки.	Хочу общаться с пользователями не прибегая к помощи сторонних мессенджеров.	Реализовать поддержку онлайн чата между пользователями и специалистами тех поддержки.	Сделать онлайн чат для тех поддержки. Только view.
Специалист тех поддержки.	Хочу просматривать информацию о пользователе и его заказах.	Повысить эффективность своей работы и не спрашивать глупые вопросы (номер заказа и тд.).	Предусмотреть уровень прав для спецов из тех поддержки. Только view, ограниченные edit права.
Владелец бизнеса.	Хочу все видеть и контролировать.	Быть в курсе всего происходящего.	Реализовать админку с широким уровнем view прав.

Итого можно выделить 3 основные направления которые будет пытаться релизовать наше приложение/сервис:

1. Удобная и адаптивная площадка для покупок товаров собственного производства.
2. Система трекинга и записи тренировок.
3. Социальная составляющая: личные сообщения, профили юзеров, возможности комментирования, создания чат групп.

Базовый сценарий использования будет следующим: зарегестрированный пользователь переодически заходит в наше приложение посмотреть на тренировки его соседей/друзей/знакомых, иногда оставляет комментарии, иногда записывает свои тренировки, попутно получая персоналные предложения адаптированные конкретно под него, совершает переодически покупки. Пользователь очень рад и советует наше приложение своим друзьям/знакомым.

Помимо требованиий пользователя на функциональные требования влияют следующие крайне важные факторы:

1. Законодательные требования. На текущем этапе не выявлено никаких препятствий к реализации нашего сервиса/приложения, кроме как требование озвученные в ФЗ 152 "Закон о персональных данных". В соотвествии с которым мы обязаны хранить персональные данные пользователей на территории РФ. Так как исходя из условия текущего задания мы пользуемся облачными провайдерами, то велика вероятность что наша компания пользуется сервисами AWS/GCP. Текущий закон безусловно считается ограничением, но не критичным. Также важно отметить требования PCI DSS, в соотвествии с которыми мы не можем хранить информацию о банковских картах пользователей в наших системах баз данных. Мы можем это делать только получив соотвествующую (труднополучимую) лиценизю.
2. Требования регулятора. Мы не финансовая/игорная/букмекерская организация и под требования регулятивных органов в превычном их понимании не попадаем.
3. Физические ограничения. Так как мы размещаемся в облаке то любое ограниче это вопрос суммы чека за предоставляемый хостинг, это значит что любые ограничения подобного типа вытекают из бюджета на реализацию и поддержку.
4. Финансовые ограничения. Неизвестно но будем полагать что их нет, ограничения вытекают исходя из здравого смысла.
5. Прочие ограничения. Сюда бы я отнес ограничения специфичные для нашего контекста. Ввиду того что потенципльные потребители будут общаться с нашим сервисом с мобильных устройств, им свойственно иметь некоторые проблемы с передачей информации: низкая скорость интернета, особенно в регионах, обрывчатый характер связи. Усубляет положение то, что наши пользователи будут пользоваться приложением "в полях": на пробежках, прогулках, покатушках, вдали от цивилизации.

Анализ и описание архитектурных опций и обоснование выбора.

Существует два основных типа архитектуры:

1. Монолитная архитектура.
2. Распределенная архитектура.

Рассмотрим таблицу ниже:

Следует помнить одну очень важную вещь:

​ Золотое правило микросервисной архитектуры - не делать микросервисную архитектуру.

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

Некоторые архитектуры с их плюсами и минусами уже отображены в таблице выше:

1. Монолитная архитектура. Самый простой вариант, легок, понятен, дешев. Хорош при небольших размерах приложения. С ростом числа пользователей и RPS начинает не справляться с нагрузкой в геометрической прогрессии, не наш вариант.
2. Распределенный монолит. Переходный вариант между монолитом и распределенной архитектуры, который сочетает оба подхода. Компромисный вариант, полумеры, не наша остановочка.
3. Micro-Kernel. Тип расрпделенной архитектуры, в которой функционалость подключается как блоки. Например чудесный сайт под названием Skillbox.ru работает на этой арзитектуре. Хорош для приложений которые продают контент или доступ к нему. Тоже не наш вариант.
4. Микросервисная архитекура. Сложно, долго, дорого. Но в долгосрочной перспективе максимально выйгрышный вариант. Наш выбор, наш кандидат.

В таблице выше не представлены сторонние подвиды микросервисной архитектуры:

1. SOA (Service oriented). Первая попытка создания расрпделенной архитектуры. ESB сильно усложняли коммуникацию между сервисами. Признана сообществом как неудачная.
2. SBA (Service Based). Неплохой вариант но по сути тоже самое что и распредленный монолит: переходная стадия от монолита к распредленной. У данного типа архитектуры есть одно очень существенное ограничение: он предолагает единую базу для всех сервисов. При росте числа пользоателей это может и будет бутылочным горлышком нашего приложения. Помимо этого существенные ограничения на параллельное развитие сервисов, вопросы миграций баз данных и синхронизация изменений в БД.
3. SBA (Space Based). Чрезвычайно сложное и дорогое архитектуное решение. Реализация такого проекта может растянуться на долгие годы. Не наш вариант.
4. Event Driven. Состоятельное архитектурное решение для всей системы, которое имеет как свои плюсы так и минусы, к минусам которого можно отнести достаточно высокую сложность такого решения, его поддержку, отладку, создание компенсационных механизмов. К Event Driven подходу можно прибегнуть в отдельных частях нашего будущего приложения: например в отдельных интеграциях между сервисами.

Распределнная архитектура в лице микросервисов решает следующие проблемы:

1. Доступность. Микросервисы могут быть реплицированы в любом колличестве в любой тайм зоне и автоматически.
2. Автономность. Микросервисная архитектура подразумевает максимальную независимость одного сервиса от другого.
3. Возможноть изменений и параллельного развития. Ввиду независимости каждый сервис можно развивать параллельно не мешает другим сервисам.
4. Поддерживаемость. Также вытекает из автономности. Обычно за каким-то микросервисом закрепляется своя команда разработчиков, которые знают его как свои пять пальцев.
5. Секьюрно. Можно настроить гибкий высокий уровень защиты и прав.
6. Масштабируемость. Реплицируется до бесконечности.

Но следует отметить и следующие минусы:

1. Сетевые проблемы. Об этом подробнее ниже.
2. Интерфейсы и интеграции. Чем больше микросервисов и интерфейосов через которые они общаются - тем больше интеграций, значит больше потенциальных точек отказов. Слабое место всех расрпделенных архитектур.
3. Проблемы с балансировкой и обнаружением. Если микросервисы могут реплицироваться, то нужен тот кто будет делать эти реплики, регистрировать их в реестре и распределять нагрузку между ними. Дополнительное сложное звено системы и еще одна большая точка отказа.

Про сетевые проблемы можно сказать следующее:

1. Сеть не надежна. Обрывы соединений, нестабильность - боль с которой придется жить.
2. Даже самая быстрая сеть подразумевает задержки (latency), это дополнительное ограничение которое в будущем может встать боком.
3. Пропускная способность ограничена, тем же самым гигабитом. Данная проблема решается за очень большие деньги и прокладкой своих кабилей в дата центр провайдера.
4. Сеть небезопасна. В нее можно внедриться, воровать трафик, прослушивать. Влечет за собой дополнительные траты на обеспечение безопасности.
5. Сеть неодонородна, в ней множество устройств которые должны общаться меж собой и которые ввиду своей неидеальной природы глючат/ломаются/перезагружаются.

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

PAAS провайдер, такой как Google или AWS практически полностью закроет наши проблемы с сетью, репликацией, балансировкой и обнаружением. Единственной проблемой которой нам все еще предстоит решать это сами микросервисы и интеграции между ними.

Крайне важно отметить, что выбор PAAS решения полностью закрывает один из основных ФТ: Доступность приложения в любой точке земного шара. Наше приложение можно будет сделать доступным на других континентах просто кликом мышки.

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

Кроме того что у нас будет распредленная система, мы прибегнем еще к N-tier решению.

У нас будет отдельный слой с презинтацией данных, здесь мы будем сериализовывать и десериализовывать данные. В бизнес слое будет происходить вся бизнес логика нашего приложения. Data access layer и DB layer будет отвечать за хранение и доступ к информации. Данный подход является классическим в подобных решениях.

Помимо этого некоторые API точки нашего приложения будут реализовывать CRUD принципы.

Заранее можно сказать что одной из таких точек будет точка по редактированию состава корзины товаров.

При проектировании низкоуровенвых решений (микросервисов и их частей) мы будем полагаться на закон Конвея, который звучит как:

​ «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации»

А также будем полагаться на DDD подход, будут выделены доменные области, выработан общий язык, выделены агрегаты, сущности, объекты-значения.

Анализ стейкхолдеров и их интересов.

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

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

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

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

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

В контекте нашей задачи во внешнюю группу стейкхолдеров я бы выделил:

1. Пользователи нашего приложения.
2. Государство в виде регулирующего органа и различных законов.

Во внутреннюю группу:

1. Владельцы бизнеса и их представители. Сюда же можно отнести миноритариев, инвесторов, бизнес партнеров, углубляться можно бесконечно. В рамках дипломного проекта по Архитектуре ПО нам важно выделить всех указанных в данном пункте стейкхолдеров просто как бизнес.
2. Реализаторы проекта: программисты и прочие специалисты (devОps, designerers, QA).
3. Продукт менежер или тот кто будет вести проект на этапе его разработки и поддержки. Его можно было бы отнести в группе реализаторов проекта, но его уровень важности и вовлеченности отличается.
4. Маркетологи или те кто будут продвигать проект.
5. Будущие низкоуровенвные технические работники проекта: контент менеджеры, работники поддержки, авторы текстов.

Всех вышеназванных стейкхолдеров я б разместил в диаграмме в следущем виде:

Конечно в первую очередь мы должны удовлетворять интересы бизнеса, это первоочередная задача. У бизнеса один главный интерес: получение прибыли.

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

Нельзя не считаться и с интересом самих разработчиков, их мнение и заинтересованность важны. Разработчики хотят четкое и понятное ТЗ, некоторую свободу в ходе выполнения задач и общую интересность поставленных задач.

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

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

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

Еще более менее заинтересованными сторонами можно назвать специалистов тех. поддержки, контент менеджеры и прочие низкоуровневые специлисты. Им вообще без разницы что там и как, дайте лишь возможность осуществлять прямо возложенную на них деятельность и все.

Описание рисков реализации (бизнес и технические).

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

Мы имеем следующие бизнес риски:

• На рынке уже существуют подобные фитнес трекеры, которые имеют большую пользовательскую базу и отточенные бизнес механизмы. Мы можем не выйграть в конкурентной борьбе. Тык.
• Шансы на успех понижает встраиваемаяя нами реклама наших товаров, никому не нравится реклама, даже самая деликатная и ненавязчивая. Более того на рынке совершенно точно будет аудитория которой не нравится наш товар, это оттолкнет их к скачиванию нашего приложения, что скажется на общем колличестве аудитории.
• Предыдущий риск влечет за собой следующий: публичные фитнес трекеры, где пользователи могут записывать свои тренировки и потом делиться ими - основаны на низменных человеческих желаниях выделиться и самоутвердиться. Это все становится бессмысленным если в приложении нет аудитории и самоутверждаться не перед кем.
• Смело можно утрвеждать что будет аудитория которая все же будет пользоваться нашим приложением, но не будет приносить никакого profit. Такие люди будут потреблять мощности нашего backend сервиса и наших баз, но не покупать товары. Если процент такой аудитории будет слишком велик, то окупаемость проекта останется под вопросом.

Законодательные риски:

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

Технические риски:

• Микросервисная архитектура не самая простая в построении. Потребуются квалифицированные программисты.
• Персонала обслуживающего систему (админы, копирайтеры) может не хватить при резком росте трафика в приложении.

Риски которая влечет за собой микросервисная архитектура:

• Deployment. В микросервисной архитектуре слаженный деплой множества отдельных приложений не является тревиальной задачей.
• Tracing. Разбираться почему что-то сдало сбой в сложной микросервисной архитектуре можно очень долго и сложно. Требуется введение дополнительных систем для трейсинга и обнаружения проблем.
• Integrations. Самое слабое звено микросервисных архитектур. На интеграциях ломаются все системы подобного рода, проблемы подобного рода неизбежны.
• Dependency. Как сильная так и слабая сторона микросервисной архитектуры. Если меняются интерфейсы или меняется структуры базы данных в одной системе - это влечет за собой по цепочке изменение всех остальных сервисов которые завязаны на изменяемом. Также головная боль с поддерживаем версионированных интерфейсов, инога legacy системы не подвержены изменениям от слова совсем, в таком случае для них придется поддерживать legacy API точки.
• Network. Риск сетевых проблем будет всегда, даже если все наши микросервисы находятся в одной облачной сети или сети компании, то есть ненулевой шанс что в процессе передачи данных что-то пойдет не так. Сеть неоднородна и в ней множество точек отказа, которыми нельзя не принебрегать.

Риски которые влечет за собой архитектура, базирующаяся на облачных решениях.

• Vendor lock. Так как мы размещаемся в облаке со стратегией Cloud Native, то переезд с одного облака на другое может быть крайне затруднительным. Также крайне трудно будет переехать и на свои мощности (on premises). Система попадает в зависимость от провайдера, если провайдер резко поменяет цены в свою пользу - нас ждет беда.
• Ввиду того что большинство зрелых облачных провайдеров находятся в США (GCP, AWS) есть существенный риск их блокировки или замедления на территории РФ уже в ближайшем времени.

Прочие риски:

• Риски исходящие от владельцев бизнеса/инвенсторов.
• Стоимостные риски. Есть риск вывалиться из бюджета.
• Риск того что команда разработчиков будет несостоятельная.
• Риск уязвимости конечного продукта к внедрениям и злонамеренным употреблениям.
• Риск неверно выбранных технологий и решений.
• Экономические риски. Как российские так и общемировые. Сюда входят риски кризисов при которых покупательская способность нашей аудитории может резко сократиться.
• Валютные риски. Риск того что мы все же российская IT компания, которая получает выручку в рублях а платит провайдеру в валюте.
• Общие риски ведения бизнеса на территории РФ, правовая незащищенность, отсутствие судебной системы.

План поэтапной разработки и расширения системы, анализ критически важных компонентов.

Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.

• Минимальными приложениями критически неоходимыми системе для выхода на рынок являются приложения Api Gataway/User и Tracking. Имея только их в арсенале уже можно потихоньку выходить на рынок и начинать робкие попытки по сбору аудитории.

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

• После можно реализовывать приложение Messaging, чтобы до конца реализовать весь возложенный на систему функционал.

• И только потом, в последнюю очередь, когда по сути вся система уже готова, стоит вводить возможность in app покупок путем реализации модуля Shop. Приучать пользователя что в приложении будет реклама (пусть и только наша и наших товаров) стоит постепенно и очень деликатно, рынок фитнес приложений крайне конкурентен и излишняя навязчивость сыграет не на пользу.

Выделение критических бизнес-сценариев.

Все оснвовные компоненты нашей системы независимы друг от друга, но зависимы от приложения Авторизации/Gateway. Если приложение авторизации ложится - остальные компоненты системы перестают работать. Ввиду этого критическим бизнес сценарием который может повлиять на работоспособность всей системы будут являться неполадки в приложении авторизации. Получается это из-за того что функционал авторизации/аутентификации является основополагающим и сквозным для всех сфер нашего приложения.

Если же сломается приложение Tracking, то тогда ничего страшного, приложение Shop, Content будут все также работать и наоборот тоже. В этом один из главных плюсов микросервисной архитектуры: слабая зависимость. При поломке одного другое продолжает функционировать.

Ввиду этого приложению авторизации следует уделять максимальное внимание:

• Пристальное наблюдение за логами 24/7.
• Внедрять раннее обнаружение, система уведомлений на почту/смс/звонки.
• Глубочайшее тестирование приложение (unit + integration).

Атрибуты качества.

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

Тем не менее это еще не все, также важной частью требований к архитектуре являются и атрибуты качества.

Глобальные атрибуты качества:

​ QA-1: Interoperability. Мы должны встроить нашу систему в уже имеющуюся систему компании, где реализованы и интернет магазины и остальные доменные области.

​ QA-2: Elasticity. Система должна выдерживать всплески нагрузки а также сезонный трафик.

​ QA-3: Reliability. Система должна быть доступна 24/7 из большинства стран мира. Простой допустим в окна с минимальным трафиком на профилактические работы.

​ QA-4: Maintainability. Система должна быть легко поддерживаемой, достигается путем применения всех актуальных паттернов проектирования и надлежащих разработчиков. Туда же относится тестируемость, анализируемость.

Атрибуты качества для модуля User/Api Gataway:

​ QA-: Security. Так как мы работаем с персональными данными пользователем критическими являются требования к безопасности данных. Все передачи информации должны быть зашифрованы, доступ к данным строго ограничен.

Атрибуты качества для модуля Content:

​ QA-: Security. Нейронные сети будут работать с персональными данными, требования схожи с аналогичными для User/Api Gataway модулем.

​ QA-: Modifiability. Разработка нейронных сетей или использование уже готовых носит динамический характер. Система должна легко поддаваться изменения и переезжать с одной рекомендательной модели на другую.

Атрибуты качества для модуля Tracking:

​ QA-: Perfomance. Менее строгие требования чем к модулю Messaging, но тем не менее данный модуль будет хранить большое колличество данных.

Атрибуты качества для модуля Shop:

​ QA-: Aviability. Продавать товары и получать с этого прибыль наша главная задача. Встроенный магазин и система оплаты должны быть доступны всегда.

Атрибуты качества для модуля Messaging:

​ QA-: Perfomance. Система должна переваривать десятки/сотни сообщений в секунды. Добиться можно только построив систему на очередях сообщений.

Анализ и список нефункциональных требований.

Если бизнес требования отвечают на вопрос "зачем", функциональные требования отвечают на вопрос "что", то нефункциональные требования отвечают на вопрос "как". Выделим НФТ для всего проекта а также для каждого модуля отдельно.

Глобальные НФТ:

• Запросы на наши API со стороны пользователя не должны превышать 500ms, в редких случаях на очень тяжелых точках (выгрузка тренировки) допуск ответа в 2000ms.
• Общий dowmtime не более часа в месяц.
• Grace Shut down в случае проникновения или взлома не дольше 5 минут.

НФТ для User/Api Gataway:

• Пользователь должен авторизовыватся при входе в систему, незарегестрированным пользователям система недоступна совсем, только landing.
• Пользователь должен получать JWT токен который он будет хранить в заголовке запросов. Срок жизни токена доступа 1 час, срок жизни токена обновления неделя. Для большей безопасности.

НФТ для Content:

• Уникальная лента пользователя должна формироваться не более чем за 1000ms.
• Количество рекламных предложений не больше 20% от объема ленты, в хаотичном порядке, чтоб пользователь не смог выработь рефлекс по инстинктивному проматыванию рекламы.
• Отдавать приоритет в отображении подпискам пользователя.
• Дать возможность смотреть ленту в хронологическом порядке.

НФТ для Tracking:

• Тренировки должны записываться на устройстве пользователя, выгрузка на сервер происходит только в конце при помощи одного большого batch. Если batch не выгрузился, повторная попытка через 1, 5, 10 минут с последующим выводом ошибок если все же не удалось.
• Ввиду этого расчет средних показателей тренировок тоже должен быть реализован на стороне пользователя (средняя скорость, средний пульс и тд.).
• Ввиду емкости операции обработка маршрута сервисом обработки не более 2 минут с начала старта.
• Реализовать отображение маршрутов при помощи точек и линий на популярных среди пользователей картах (Google Maps, Yandex Maps).
• Сбор данных пользователя во время тренировки происходит раз в 1/5/10 секунд и настраивается на стороне сервера.

НФТ для Shop:

• В случае падения оплаты со стороны пользователя не осуществлять повторных попыток списания без его ведома. Лишь учтиво показать ошибку.
• Модуль должен быть реализован таким образом чтоб пользователь не понял что система наличия товаров/доставки реализована не на нашей стороны. Для него должно выглядеть как единая связная система.
• Реализовать отображение доставки товаров в режиме реального времени также на популярных среди пользователей картах (Google Maps, Yandex Maps).

НФТ для Messaging:

• Sms сообщения должны приходить не позднее одной минуты с моменты запроса инициирующего сервиса.
• E-mail сообщения не позднее 5 минут.
• Push уведомления не позднее 10 секунд.
• Число попыток повторной отправки в случае ошибок не больше 10 для каждого сообщения.

Разработка концептуальной архитектуры.

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

Все наши пользователи будут пользоваться нашим придожением через REST HTTPS интерфейсы.

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

Следующим по значимости идет приложение Tracking app. Суть данного приложения в записи тренировок пользователей. На старте приложения будут доступны два основных типа активности: бег, велосипед. Остальные типы активности можно будет разрабатывать с ростом приложения. Tracking app записывает ключевые параметры в реляционную БД, с последующим анализом тренировок после save процедуры в базе. Для того чтоб клиентское приложение не спамило backend - выгрузка будет осуществляться только в конце тренировки одним большим (или несколькими крупными) batch. До момента выгрузки клиентское устройство само складирует координаты, время и прочуюю информацию локально. Расчет динамических значений происходит также локально.

Следующим по значимости идет Shop app. То ради чего все и затевалось, наш встроенный магазин, где мы продаем свою продукцию. Поддерживает все основные для интернет магазина компоненты: payment, checkout, cart и другие. Следует отметить что по условию задания мы находимся в среде, где весь подобный фнункционал уже реализован в рамках существующего предприятия. Все что от нас здесь требуется - наладить интеграции с уже работающими системами. Единственное что стоит сделать на своей стороне - систему оплаты, чтоб она была независима от других сервисов, а клиенты привязывали свои карты в нашем, а не в стороннем приложении.

Далее идет Content app, или то приложение что будет отвественно за feed пользователя. Данное приложение на выходе будет выдавать готовый контент для отображения в ленте с вертикальным скролом. В контент будут входить: тренировки самого пользователя (карта с отмеченным пройденным маршрутом) и ключевые показатели, тренировки других пользователей, на которые подписан user, различные статьи, а также рекомендации к тренировкам на основе анализа его тренировок. Данное приложение при должной реализации может стать той фичей, которая будут выгодно выделять нас на фоне других существующих приложений. Внедрив технологию ML/Neural Nets мы можем анализировать тренировки пользователей и реально давать дельные раотающие советы. Более того лента должна быть адаптивной и по поведению пользователя (лайки, дизлаки и тд) понимать что пользователю нравится, а что нет, и будущем давать только тот контент в feed, который с большей вероятностью будет нравиться пользователю. Данное приложение будет самым высокотехнологичным и сложным.

И последним будет инфраструктурное приложение Messaging, которое будет отвественно за уведомления пользователя, через каналы: e-mail, sms, push. По своей сути должно быть асинхронным, ввиду долгих блокирующих операций. Также messaging будет отвечать за коммуникацию внутри приложения между пользователями (чат).