Спасибо за очень внимательное прочтение статьи и за точный комментарий. Действительно есть над чем поработать.
По первому вопросу:
Здесь по тексту закралась ошибка, в публикацию попала неправильная версия фразы про API-First. Безусловно, форматы и правила описания являются частью описания API и подхода API-First.
Общая схема при проектировании системы с нуля:
Будущая система разбивается на бизнес-функции.
Среди этих функций мы определяем те, которые должны быть доступны в виде API, определяем первичных потребителей.
Определяем эти API — по части самой структуры данных обмена и других характеристик.
Генерируем код относительно подготовленных описаний на стороне поставщиков и потребителей.
Определяем все API — получение информации о клиенте, получение информации о магазине, регистрация заказа для магазина, предоставление информации о товарах в наличии от магазина и т.д.
Формируем описания всех API от поставщиков.
Генерируем код, получаем основу для своих сервисов.
По факту в описанном мной случае, когда ИТ-ландшафт уже сформирован, приходится не проектировать с нуля, а просто вносить изменения в уже реализованные интеграции. Тут всё проще.
По второму вопросу:
Head профессии — это новая роль в организации, но пока только в одном из направлений, при этом достаточно крупном (несколько сотен экспертов). Это можно масштабировать и на весь Банк.
По факту это лидер экспертизы, т.е. специалист, наиболее подкованный в данной профессии. Он не является непосредственным руководителем всех экспертов, но в его обязанности входит следующее:
— Внедрение единого стандарта в профессии. — Внедрение релевантных инженерных практик и инструментов. — Внедрение единой процедуры собеседований, онбординга и оценки сотрудников. — Построение профессионального сообщества, а также внутренних и внешних коммуникаций этого сообщества.
Таких хэдов может быть несколько даже в рамках одной профессии на одном направлении, они при этом всё равно работают в конкретной команде и выполняют в том числе и прикладные задачи, помимо задач области хэда профессии.
Сам факт отправки или получения сообщения не является 100-процентным признаком потребителя или поставщика. Нужно смотреть на данные и прикладную логику. Главное — не отправитель/получатель, а более глубокое понятие поставщик/потребитель.
Поставщик является владельцем предоставляемых функций/данных и в конечном итоге владельцем этого API, так как определяет основу для его функционирования — в отличие от потребителя, который просто использует этот API.
При этом варианты работы API могут быть разные: поставщик может принимать входящее сообщение и отвечать одним или несколькими сообщениями потребителю или может публиковать сообщение на нескольких потребителей по подписке и т.д. Но принцип остаётся один: все спецификации API (включая все составляющие его запросы и ответы) хранятся на стороне поставщика этого API.
1. Поэтому в указанном случае необходимо определить к каким/какому API относится сообщение FormatA и сообщение FormatB и главное — какой из сервисов A/B является поставщиком этих/этого API. Могут быть разные расклады.
2. Правило остаётся таким же при росте количества сервисов и усложнении взаимодействий.
За лайфхак спасибо, обязательно попробуем, у нас в итоге вся кодогенерация пока свелась к формированию DTO, не более.
Спасибо за очень внимательное прочтение статьи и за точный комментарий. Действительно есть над чем поработать.
По первому вопросу:
Здесь по тексту закралась ошибка, в публикацию попала неправильная версия фразы про API-First. Безусловно, форматы и правила описания являются частью описания API и подхода API-First.
Общая схема при проектировании системы с нуля:
Будущая система разбивается на бизнес-функции.
Среди этих функций мы определяем те, которые должны быть доступны в виде API, определяем первичных потребителей.
Определяем эти API — по части самой структуры данных обмена и других характеристик.
Генерируем код относительно подготовленных описаний на стороне поставщиков и потребителей.
Пример:
Разрабатываем систему заказа продуктов.
Выделяем бизнес-функции — регистрация клиента, регистрация магазина, поиск магазинов, заказ из выбранного магазина.
Определяем все API — получение информации о клиенте, получение информации о магазине, регистрация заказа для магазина, предоставление информации о товарах в наличии от магазина и т.д.
Формируем описания всех API от поставщиков.
Генерируем код, получаем основу для своих сервисов.
По факту в описанном мной случае, когда ИТ-ландшафт уже сформирован, приходится не проектировать с нуля, а просто вносить изменения в уже реализованные интеграции. Тут всё проще.
По второму вопросу:
Head профессии — это новая роль в организации, но пока только в одном из направлений, при этом достаточно крупном (несколько сотен экспертов). Это можно масштабировать и на весь Банк.
По факту это лидер экспертизы, т.е. специалист, наиболее подкованный в данной профессии. Он не является непосредственным руководителем всех экспертов, но в его обязанности входит следующее:
— Внедрение единого стандарта в профессии.
— Внедрение релевантных инженерных практик и инструментов.
— Внедрение единой процедуры собеседований, онбординга и оценки сотрудников.
— Построение профессионального сообщества, а также внутренних и внешних коммуникаций этого сообщества.
Таких хэдов может быть несколько даже в рамках одной профессии на одном направлении, они при этом всё равно работают в конкретной команде и выполняют в том числе и прикладные задачи, помимо задач области хэда профессии.
Сам факт отправки или получения сообщения не является 100-процентным признаком потребителя или поставщика. Нужно смотреть на данные и прикладную логику. Главное — не отправитель/получатель, а более глубокое понятие поставщик/потребитель.
Поставщик является владельцем предоставляемых функций/данных и в конечном итоге владельцем этого API, так как определяет основу для его функционирования — в отличие от потребителя, который просто использует этот API.
При этом варианты работы API могут быть разные: поставщик может принимать входящее сообщение и отвечать одним или несколькими сообщениями потребителю или может публиковать сообщение на нескольких потребителей по подписке и т.д. Но принцип остаётся один: все спецификации API (включая все составляющие его запросы и ответы) хранятся на стороне поставщика этого API.
1. Поэтому в указанном случае необходимо определить к каким/какому API относится сообщение FormatA и сообщение FormatB и главное — какой из сервисов A/B является поставщиком этих/этого API. Могут быть разные расклады.
2. Правило остаётся таким же при росте количества сервисов и усложнении взаимодействий.
За лайфхак спасибо, обязательно попробуем, у нас в итоге вся кодогенерация пока свелась к формированию DTO, не более.