Описание основных бизнес-процессовASIS

Рассмотрим ряд существующих бизнес-процессов, которые осуществляются через интернет-банк.

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

 

 

Рисунок 12 - Диаграмма последовательности для процесса “Создание платежа в Rapida”

 

В этом процессе пользователь осуществляет выбор того или иного агрегатора платежа (Билайн, Мегафон и многие другие)[10], а потом осуществляются различного рода валидации входных параметров, например, наличие денег на балансе, корректность ввода номера телефона и другие параметры платежа. После успешного прохождение всех необходимых проверок, осуществляется отправка платежа в систему Rapida. Также предусмотрена отправка платежа в случае, если система Rapidaбудет недоступна в нужный момент времени. Для этого может использоваться процедура, вызываемая по расписанию. На рисунке 12 показана диаграмма последовательностей для такой процедуры. Во многом она походит на ту, что изображена на рисунке 11.

 

Рисунок 12 - Процедура повторной отправки платежа в Rapidaчерез процедуру.

 

Также интернет-банк интегрируется с системой обработки платежей PaymentHub, в котором каждый из агрегаторов платежей содержит свои собственные платежные параметры. Бизнес-процесс представлен на рисунке 13.

Рисунок 13 -Отправка платежа в PaymentHub

 

Этот процесс похож на Rapida-процесс, за исключением того, что здесь допустимы совершенно разные параметры для разных агрегаторов платежей [12]. Для одного агрегатора нужно вводить номер телефона, для другого нужно вводить номер телефона и номер квартиры. Но в целом процесс аналогичен с процессом Rapida. Точно также есть процедура по расписанию отправки платежа в систему PaymentHub (рисунок 14).

 

Рисунок 14 - Повторная отправка платежа в PaymentHub

 

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

 

Рисунок 15 - Схема работы переводов между своими счетами.

 

повторной отправки перевода по расписанию в случае неудачи не предусмотрена 13].

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

 

Рисунок 16 - Межбанковский перевод

 

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

Также через интернет банк доступны такие бизнес-операции, как оформление заявки на кредит и депозит. Процесс оформления этих банковских продуктов в целом очень похож – клиент оставляет заявку на тот или иной банковский продукт, а оператор через административную панель его подтверждает. Рисунки 17 и 19 наглядно показывают процесс заведения соответствующих заявок.

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

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

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

Рисунок 17. Процесс оформления заявки на вклад.

 

Рисунок 18. Подтверждение банковской операции

 

 

Рисунок 19. Оформление и подтверждение заявки на кредит

 

Рисунок 20 - Инициация автоплатежей и автопереводов в интернет-банке со стороны внешней системы.

 

Сложности разработки данной системы добавляет и возможные миграции платежей, например, когда существует шаблон перевода, созданный для системы Rapida, и его пытаются применить для работы с PaymentHub [15].

Декомпозиция системы

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

Основные бизнес-операции, которые были выделены в предыдущем пункте:

- Просмотр истории платежей и переводов

- Осуществление платежей и переводов с нуля, из шаблонов, из истории

- Создание шаблонов переводов

- Создание и инициация автоплатежей

- Управление и просмотр банковских продуктов

- Оформление заявки на кредит

- Оформление заявки на вклад

Придерживаясь концеции «Один микросервис – одна бизнес-функция», но в разумных пределах, спроектируем «черновую»модель интернет-банка на микросервисной архитектуре, представленную на рисунке 21.

 

Рисунок 21 - Предполагаемая модель архитектуры интернет-банка

 

Здесь представлена реализация паттерна «Агрегатор» где в роли агрегатора выступает так называемое фронт-приложение, которое осуществляет вызовы остальных микросервисов [16]. На рисунке 22 наглядно представлено абстрактная модель реализации данного паттерна.

 

 

Рисунок 22 - Паттерн “Агрегатор”

 

Этоодин из наиболее распространенных паттернов проектирования при работе с микросервисами. Но в данном случае здесь фронтовое приложение не является «чистым» прокси, а представляет собой довольно внушительный микросервис, который вызывает остальные той или ной целью. База данных данного микросервиса содержит в себе пользовательские данные, такие как логин, захешированные пароли, различные пользовательские настройки. Также данный микросервис предоставляет интерфейс внешней системе для того, чтобы можно было заводить и подключать к интернет-банку новых пользователей. Однако упомянутая система не входит в контур системы интернет-банка [17].

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

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

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

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

Также на рисунке 25, рисунке 26 и рисунке 27 наглядно представлены декомпозиции микросервисов дебетовых, кредитных продуктов и вкладов соответственно. Поскольку легче создать новый микросервис, который имплементирует в себе работу с определенным типом продукта, чем пытаться реализовать на существующей архитектуре микросервиса, то такая декомпозиция оправдана. Это идет в соответствии с законом Лемана об усложнении программного обеспечения и ухудшения качества, поскольку однажды сформированная архитектура неизбежно устаревает и может не предусматривать те бизнес-требования, которые могут предъявляться к системе со стороны заказчика.

 

Рисунок 23 - Декомпозиция микросервиса межбанковских переводов.

 

Рисунок 24 - Декомпозиция микросервиса платежей.

 

 

Рисунок 25 - Декомпозиция микросервиса дебетовых продуктов.

 

 

Рисунок 26 - Декомпозиция микросервиса кредитных продуктов.

 

 

Рисунок 27 - Декомпозиция микросервиса вкладов