Главное Свежее Вакансии Образование
😼
Выбор
редакции
452 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Микросервис биллинга: история проекта, закрытого в срок

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

Когда можно назвать проект успешным? Для меня это:

  • уложиться в сроки;
  • уложиться в бюджет;
  • закрыть все требования по ТЗ.

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

На связи команда ZAKUPKI.GROUP и ее COO Алексей Николаев. Мы проектируем корпоративное ПО на Java EE.

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

Но самое интересное началось, когда к нам пришел клиент — экосистема для проведения турниров по играм Apex Legends. Изначально они сами не понимали, чего хотят, как это часто бывает с заказчиками. Около полугода мы согласовывали, что будем делать, и в итоге решили: нужен продукт, осуществляющий прием/выплату и внутреннее движение средств. И мы приступили к разработке микросервиса биллинга с модульной архитектурой, который плавно бы вписался в сервера и приложения клиента.


Вот как выглядела самая первая диаграмма по проекту: доменная модель терминов предметной области

Этап аналитики


В то время у нас в команде не было аналитиков. Сбором функциональных и нефункциональных требований, построением диаграмм занимались разработчики. Естественно, это происходило под чутким контролем CTO, и результат получился достойным. Но насколько было бы легче с аналитическим отделом! К слову, сейчас он у нас уже сформирован, и теперь разработчики занимаются своими прямыми обязанностями, и даже не выгорают и не увольняются! (Да, было и такое, но это тянет на отдельный лонгрид)

Вместе с клиентом мы долго и методично разрабатывали ТЗ, и вот основные моменты, к которым мы пришли:

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

  1. Процессинг платежей
  2. Работа с платежными системами
  3. Админка статистики/управления

SL

  1. Микросервис должен быть доступен 24/7/365
  2. Максимальное время аварийного даунтайма не должно превышать время ответа для платежной системы

В разработке считается, что превышение заложенного времени в 3 раза — это еще не срыв дедлайна, а норма. Но мы думаем, что срыв сроков происходит из-за недостаточной первичной аналитики. Закладывая время на работу, мы понимали, что нужно быть реалистами и не давать невыполнимых обещаний клиенту. Особое внимание уделили этапу тестирования. Он не является последним и наличие тестов не гарантирует полного отсутствия багов, поэтому за ним обычно идет этап исправлений со стороны разработки. В итоге мы не поскупились — на тестирование и на исправление багов выделили по 40 часов.


Используемые нами технологии

Сдача проекта


Итак, хорошая аналитика позволила нам спокойно и без особых помех работать над проектом, укладываясь в сроки. Однако не все зависело от нас, т. к. для интеграции платежных систем нужно пройти их внутреннюю модерацию — а значит подгонять под них клиентские сайты и заключать договоры. Такие полномочия были только у заказчика, и его приходилось периодически «пинать», напоминая о дедлайнах.

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

В итоге на работу ушло 3 месяца, клиент остался доволен, сейчас мы сотрудничаем с ним уже по другому проекту.

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

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

Буду рад любым комментариям!

Алексей Николаев, COO ZAKUPKI.GROUP / CEO NIKSOFT

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.