Схема.

Пожалуй, лучшее, что придумали айтишники.

Это описание формата взаимодействия. Схемы бывают разные, например, XSD для описания структур в формате XML, или JSON-schema - для описания структур в формате JSON.

Такое описание сейчас уже является стандартом де-факто и вот почему:

1. Удобство. Удобно один раз описать формат и далее везде этим пользоваться или переиспользовать.

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

3. Систематизация и порядок. Когда все контракты описаны в схемах, в идеале одна схема - один микросервис, налаживается порядок. Внутри алгоритмов в коде все данные не берутся непонятно откуда. За счет этого также и экономится время на разработку, тестирование и даже иногда поддержку.

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

А теперь хочу устроить небольшое обсуждение. Как вы считаете, кто в команде должен прорабатывать схему? Аналитик или разработчик?)

В моем понимании – аналитик, в таком случае схемы будут получаться максимально проработанными и с заделом на будущие доработки. Аналитик зачастую видит ситуацию по развитию системы/микросервиса шире, чем разработчик и кто-либо из команды (бывает, даже шире, чем ВП).

#быстростатья