Технологии разработки интернет-банка.

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

Интернет-банк в разных организациях выглядит совершенно по разному и может быть основан на различных технологиях. В одних случаях интернет-банк предоставляет собой один единый API как для мобильного клиента, так и для веб-клиента (Рисунок 1). Достоинство такого подхода в том, что одна команда разработки может заниматься имплементацией унифицированной бизнес-логики как для обоих видов клиентов – как для мобильного, так и для веб-клиента.

В других случаях интернет-банк для браузера – отдельная независимая система от системы мобильного банка (Рисунок 2). Такую систему могут разрабатывать разные команды, однако приходится дублировать общую бизнес-логику, если таковая присутствует.

В третьих случаях интернет-банк может предоставлять два независимых APIв контексте одной системы (Рисунок 3). Но такой вариант больше представляет собой промежуточное состояние, которое рано или поздно должно перейти к одному из вышеперечисленных.

Рисунок 1 -Единая система

Рисунок 2 -Отдельные системы для мобильного и интернет банков

Рисунок 3 -Промежуточное состояние системы интернет-банка

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

Система интернет-банка обычно выстраивается горизонтальным способом, согласно одной из вариаций MVC[6](рисунок 4).

Рисунок 4 - Обобщенная схема устройства приложения интернет-банка с точки зрения разработки

Рассмотрим схему поподробнее.

В первую очередь важно хранилище данных, обозначенное на рисунке 4. Как правило, банки используютSQL СУБД от компании Oracle, предоставляющая широкие возможности по управлению и сохранению данных[7].

DAOуровень – это интерфейс работы с базой данных. DAOуровень предоставляет несколько типовых операций по отношению к различным сущностям в базе данных, или, если по другому, таблицам. На рисунке 5 представлена примерная схема данных типового интернет банка. Однако стоит учесть, что это очень приблизительная схема данных и действительности таблиц в системах ДБО гораздо больше и порой количество переваливает за сотню.

Managerуровень – это уровень stateless-компонентов, которые содержат в себе общую бизнес-логику для различных модулей приложения (как для фронтовых jsf-компонентов, так и для RESTAPIи уровня внешней интеграции).

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

Уровень бинов (Beanlevel) представляет собой слой jsf-бинов, которые содежат в себе бизнес-логику, специфичную именно для тяжеловечного xhtml-фронта, если таковой присутствует в системе, потому что в последние годы от такого фронта стараются избавиться ввиду его сложности и неудовлетворяемости сегодняшним вызовам.

Уровень RESTAPI – это имплементация логики, которая используется мобильными и веб-клиентами. Как правило, механизм аутентификации и авторизации основывается на применении технологийтокенов, например, JsonWebToken и протоколов аутентификации наподобе OAuth 2.

Уровень внешней интеграции (Externalintegrationlevel) – это механизмы интеграции со внешними системами, где интернет-банк представляет собой систему-потребитель данных. То есть извне поступает запрос на исполнение какой-либо бизнес-операции через SOAPили REST.

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

Уровень интеграции (Integrationlevel) – это механизмы отправки запросов во внешние системы банка, например, отправка транзакции на исполнения, получение дебетовых или кредитных продуктов, получение истории платежей, баланса и так далее.

Поддерживать разработку на должном уровне качества может команда из количества человек не более семи, потому что согласно иследованиям Миллера 1956 года именно такое число “кусков” информации может одновременно обработать один человек. Не более. Также в учебнике по методологии Scrumуказано, что команды из более 9 человек становятся трудноуправляемы и необходима грамотная декомпозиция. При этом Product Owner не считается участником команды.

Рисунок 5 - Схема данных