А чем отличается унарный gRPC от Rest? В Rest Api у нас есть эндпоинт, который обрабаывает хендлер, то есть когда мы дергаем эндпоинт, то по сути мы запускаем функцию, которая уже дальше идет по слоям кода. С унарным gRPC также, мы дергаем функцию. Конечно, есть разница в http2, protobuf и тд. Но я про концепцию, в унарном gRPC и Rest вызывается функция)))
В пункте про стейкхолдеров мы их расписываем, а в BACCM мы их дублируем из пункта про стейкхолдеров, это помогает лучше понять их роли, интересы и ожидания, а также обеспечить согласованность в описании и анализе их требований и влияния на проект.
Насчет первого пункта частично согласен, но для новичка будет достаточно сложно сразу писать в openapi, также я указал, что можно это делать в openapi или blueprint форматах. Моя цель из пункта про API - указать главные параметры, которые надо фиксировать. Также в docs as code часто прописывают вручную, не у всех есть частичная генерация доки. Ну и тут еще зависит от подхода, если у нас Api first, то генерация openapi подходит, если же сначала дока, а потом код, то тут уже генерация openapi не подойдет. Но в целом - конечно гораздо лучше сразу использовать openapi, если подходы позволяют
Насчет второго - полностью согласен, решил для наглядности показать на русском языке
На практике испробован, как в небольшой компании/стартапе, так и в крупной. Проекты - цепочка поставок/ритейл.
В процессе согласования участвовали разработчики и руководители. С этим проблем не было.
Данный документ (скорее это правильно назвать спецификацией) можно смело использовать прямо в качестве тз. Тут у нас описание контракта, взаимодействия сервисов, описание бд, а также флоу пользователя и навигация по экранам/ui.
На самом деле сюда можно добавить статусную схему для разных сущностей продукта (если есть необходимость)
Можно назвать и так. Суть в том, чтобы для описанных артефактов в разделе "Бизнес-логика", не плодить несколько разделов, а упаковать все спецификации для бэкенда в один раздел.
Очень велика вероятность, что будут приколисты, которые будут это абузить с возможным вредом для здоровья. Но я думаю, что компании гиганты найдут выход из этой ситуации
А чем отличается унарный gRPC от Rest? В Rest Api у нас есть эндпоинт, который обрабаывает хендлер, то есть когда мы дергаем эндпоинт, то по сути мы запускаем функцию, которая уже дальше идет по слоям кода. С унарным gRPC также, мы дергаем функцию. Конечно, есть разница в http2, protobuf и тд. Но я про концепцию, в унарном gRPC и Rest вызывается функция)))
В пункте про стейкхолдеров мы их расписываем, а в BACCM мы их дублируем из пункта про стейкхолдеров, это помогает лучше понять их роли, интересы и ожидания, а также обеспечить согласованность в описании и анализе их требований и влияния на проект.
Это лишь пример оформления НФТ. Я так и указал в гайде
Привет! Спасибо за коммент
Насчет первого пункта частично согласен, но для новичка будет достаточно сложно сразу писать в openapi, также я указал, что можно это делать в openapi или blueprint форматах. Моя цель из пункта про API - указать главные параметры, которые надо фиксировать. Также в docs as code часто прописывают вручную, не у всех есть частичная генерация доки. Ну и тут еще зависит от подхода, если у нас Api first, то генерация openapi подходит, если же сначала дока, а потом код, то тут уже генерация openapi не подойдет. Но в целом - конечно гораздо лучше сразу использовать openapi, если подходы позволяют
Насчет второго - полностью согласен, решил для наглядности показать на русском языке
Благодарю!
На подлодке я бы побывал! :)
Неплохо!
Данная статья сподвигнула на подумать о том, когда документации много и это тоже не всегда удобно
Главное чтобы СБ не заглянула :)
Классный подход. Прост в использовании и фиксации. В некоторых случаях действительно предпочту использовать его.
До вашего комментария не слышал о таком подходе. Даже загуглить не так просто :)
На практике испробован, как в небольшой компании/стартапе, так и в крупной. Проекты - цепочка поставок/ритейл.
В процессе согласования участвовали разработчики и руководители. С этим проблем не было.
Данный документ (скорее это правильно назвать спецификацией) можно смело использовать прямо в качестве тз. Тут у нас описание контракта, взаимодействия сервисов, описание бд, а также флоу пользователя и навигация по экранам/ui.
На самом деле сюда можно добавить статусную схему для разных сущностей продукта (если есть необходимость)
Благодарю! Не отказался бы еще и от лавандавого рафа :)
Можно назвать и так. Суть в том, чтобы для описанных артефактов в разделе "Бизнес-логика", не плодить несколько разделов, а упаковать все спецификации для бэкенда в один раздел.
Ограничения всегда можно наложить, а вот снять их гораздо сложнее. Да и вне РФ это не так актуально :)
Как вам подход без использования саб тасок, то есть без подзадач, только эпики, задачи ну и баги со спайками?
Очень велика вероятность, что будут приколисты, которые будут это абузить с возможным вредом для здоровья. Но я думаю, что компании гиганты найдут выход из этой ситуации