1.33M
Категория: ПрограммированиеПрограммирование

Как мы строим мост между front и back

1.

Как мы строим мост между front и back

2.

Структура доклада
Цели
• Выстроить взаимодействие команд разработки
• Переиспользовать код для сериализации и парсинга данных
Решение
• Подготовка модели данных в Sparx Enterprise Architect (UML Class diagram)
• Согласование модели
• Автоматическое формирование JSON schema и примеров на основе модели
• Архитектура на основе модели
• Автоматическая валидация данных по схеме
• Использование заглушек (mockups)

3.

Выстроить взаимодействие команд разработки
• Готовый продукт имеет жёсткие сроки релизов
• Front-end и back-end разрабатываются параллельно,
разными командами
• Формат передачи данных становится известным
только в самом конце

4.

Переиспользовать код для сериализации и парсинга
В интернет-банке 30+ различных видов экранных форм (документы, заявления и т.п.)
И у них очень много общего

5.

Переиспользовать код для сериализации и парсинга
Одинаковые сущности должны выглядеть одинаково

6.

7.

Что мы сделали

8.

Хотим как можно раньше
получить спецификацию
формата обмена
Хотим выделять общие
части объектов и
переиспользовать их
• Подготовка модели данных в виде UML Class Diagram
• Нужен инструмент моделирования с возможностью переиспользования сущностей
• Коллективная работа с моделью

9.

Модельный репозиторий в Sparx Enterprise Architect

10.

Sparx Enterprise Architect
Плюсы
• Один из флагманских продуктов в классе Software modelling
• Множество функций для создания Class Diagram
• Поддержка повторного использования сущностей, гибкие возможности трассировки
• Отличная поддержка UML
• Поддержка коллективной работы
• Есть web-клиент. Просмотр модели в браузере без установки десктопного приложения
• Уже использовался в банке
Минусы
• Сложный, не интуитивный интерфейс
• Много лишних функций, для продуктивной настройки нужна настраивать под себя
• Нужен курс молодого бойца, чтобы не прострелить себе ногу
• Коллективная работа не удобна (lock/release)

11.

Модель данных
Информация о документе
Номер
Дата
Статус
Сумма в валюте
Сумма
Валюта
Подразделение банка
Наименование
Местоположение
БИК
Организация
Наименование
ИНН
Ответственное лицо
ФИО
Телефон

12.

Модель данных
Информация о документе
Номер
Дата
Статус
Сумма в валюте
Сумма
Валюта
Кредитная заявка
Срок кредита
Дата предоставления кредита

Подразделение банка
Наименование
Местоположение
БИК
Организация
Наименование
ИНН
Ответственное лицо
ФИО
Телефон

13.

14.

Что получили
• Визуализация структуры данных помогает при согласовании
• Сразу заметны общие сущности
• Проектирование формата обмена превращается в конструктор
• Модель можно подготовить быстро и на ранних стадиях работы

15.

Бонусы
• Чем полнее модель, тем меньше надо описывать с нуля
• «А где у нас передаётся счёт»?

16.

Модель – это хорошо, но…
Модель может быть прочтена по-разному
Проверка реализации по модели – только вручную
Схемы данных (XSD, JSON Schema)

17.

JSON Schema
• Описывает структуру JSON данных
• Читается и человеком (с натяжкой) и машиной
• Позволяет выполнять валидацию данных

18.

Генерация JSON Schema по модели
EA Schema Composer

19.

Минусы JSON Schema
1. В больших схемах сложно ориентироваться
2. Описание сущностей и их исопльзование разнесено,
приходится постоянно скроллить туда-сюда
3. Надо изучать
4. «А примеры-то есть?»

20.

Генерация примера по схеме
1. Web-версия: https://json-schemafaker.js.org/
2. Npm-пакет для Node.js:
https://github.com/json-schemafaker/json-schema-faker

21.

К чему мы пришли
Front-end
Developer
Разработка Front-end на
заглушках (mockups)
Переключение
c заглушек на
разработанный
API
Согласование
модели
Back-end
Developer
System
Analyst
Подготовка
модели
данных
Разработка API
Генерация
JSON Schema
и примеров
Внесение изменений в модель
Валидация
разработанного
API
+ доработка
Front-end и API
English     Русский Правила