Comments 5
Как минимум, п.1 - Анализ бизнес-требований - не является шагом по проектированию API. Пункты 2 и 3, скорее всего, тоже.
Доказательство от противного: в результате анализа БТ архитектор принял решение убрать пару микросервисов в один сервис. И где здесь проектирование API?
API - лишь один из способов реализации технических (системных) требований системы, а не бизнес-требований.
Как вариант (не универсально): БТ - Функц.Т - СистемныеТ - арх.решение, и потом только начинается проектирование API. В вашем примере - это где-то после п.3 (который необязательно реализуется именно API)
За подробный пример API - спасибо
Для того чтобы API было независимым от БТ (это идеальный вариант, к которому нужно стремиться), нужно перелопатить достаточно большое количество БТ, только после этого API становится устойчивым к изменению БТ. То есть такая зависимость так или иначе присутствует, но не всегда носит линейный характер. Проектирование API на практике не такой простой процесс, как может показаться на первый взгляд. Для этого нужен опыт, и постоянное возвращение к предыдущим шагам, чтобы проверить, все ли требования увязываются между собой.
Если рассматривать статью как инструкцию для коллег, кто ещё не проходил путь проектирования API с нуля, то на мой взгляд для некоторых шагов не хватает объяснения их назначения (в частности, 3,4 и 6) - что может быть не совсем очевидно.
В п.2 есть некоторая путаница с терминологией: по смыслу там ведь выявляются сущности предметной области, которые затем по какому-то принципу преобразуются в ресурсы API и уже лишь на 6м шаге это дело распределится по компонентам.
Спасибо за замечания! Статья является частью цикла по Design API First и рассматривать ее как отдельную инструкцию, по которой можно с нуля спроектировать API, не нужно. Все-таки для этого необходимо некоторое погружение в предметную область. Сущности предметной области, о которых идет речь в п.2, представляют собой некоторую концептуальную высокоуровневую модель, с которой начинается проектирование. Примеры таких сущностей приведены в разделе «Выявление общих компонентов и объектов автоматизации». П.6 относится больше к технической проработке (он не является обязательным, если сущностей не очень много), и он не всегда связан напрямую с п. 2.
Как мы внедряли Design API First. Показываем на примере сервиса аутентификации