D
Да. Кстати, в шаблоне не хватает владельцев (кто платит) и вообще, стейкхолдеров
полистал наш шаблон (у нас это не описание сервиса, а project initiation form), еще можно добавить поле с ответственными за сервис
Size: a a a
2020 November 20
GK
полистал наш шаблон (у нас это не описание сервиса, а project initiation form), еще можно добавить поле с ответственными за сервис
Почему?
GK
Меня вдохновил вот этот шаблон: https://chrisrichardson.net/post/microservices/general/2019/02/27/microservice-canvas.html
D
Почему?
ну в случае с микросервисами может это и необязательно. Наш шаблон все-таки на некий продукт рассчитан, а не микросервис. По полям ответственных можно понять какая команда им занимается и найти людей в случае вопросов
PD
Ну, мне не хватает в этих шаблонах:
1) Зачем этот сервис нужен (какое место на onion занимает, например)
2) Пожелания по сайзингу (включая объем генерируемых логов)
3) Как обновляется и как ведет при сбоях
4) Как масштабируется
Ну и API лучше сделать ссылкой на какой-нибудь openapi
А вот для событий - да, пока нет аналога openapi, которым можно было бы пользоваться.
1) Зачем этот сервис нужен (какое место на onion занимает, например)
2) Пожелания по сайзингу (включая объем генерируемых логов)
3) Как обновляется и как ведет при сбоях
4) Как масштабируется
Ну и API лучше сделать ссылкой на какой-нибудь openapi
А вот для событий - да, пока нет аналога openapi, которым можно было бы пользоваться.
GK
Ну, мне не хватает в этих шаблонах:
1) Зачем этот сервис нужен (какое место на onion занимает, например)
2) Пожелания по сайзингу (включая объем генерируемых логов)
3) Как обновляется и как ведет при сбоях
4) Как масштабируется
Ну и API лучше сделать ссылкой на какой-нибудь openapi
А вот для событий - да, пока нет аналога openapi, которым можно было бы пользоваться.
1) Зачем этот сервис нужен (какое место на onion занимает, например)
2) Пожелания по сайзингу (включая объем генерируемых логов)
3) Как обновляется и как ведет при сбоях
4) Как масштабируется
Ну и API лучше сделать ссылкой на какой-нибудь openapi
А вот для событий - да, пока нет аналога openapi, которым можно было бы пользоваться.
Ну так в шаблоне и говорится про ссылку openapi
Пожелания по сайзингу как-раз учтены, но про логи я действительно забыл, потому что они хранятся во внешнем по отношению к сервису хранилище
Пожелания по сайзингу как-раз учтены, но про логи я действительно забыл, потому что они хранятся во внешнем по отношению к сервису хранилище
GK
ну в случае с микросервисами может это и необязательно. Наш шаблон все-таки на некий продукт рассчитан, а не микросервис. По полям ответственных можно понять какая команда им занимается и найти людей в случае вопросов
не обязательно что?
D
Почему?
хм. "Почему?" что в таком случае?)
GK
хм. "Почему?" что в таком случае?)
Вы решили поупражняться в риторике?
D
нет, я видимо не понял вопрос. К чему относилось "почему?"
PD
Ну так в шаблоне и говорится про ссылку openapi
Пожелания по сайзингу как-раз учтены, но про логи я действительно забыл, потому что они хранятся во внешнем по отношению к сервису хранилище
Пожелания по сайзингу как-раз учтены, но про логи я действительно забыл, потому что они хранятся во внешнем по отношению к сервису хранилище
Понятно, что во внешнем - но важно, а сколько их туда отправляется )
GK
Понятно, что во внешнем - но важно, а сколько их туда отправляется )
Согласен, важно. Я уточнил, почему именно упустил этот момент)
GK
нет, я видимо не понял вопрос. К чему относилось "почему?"
Извините, это моя ошибка. Я не правильно интерпретировал ваше сообщение. Всё верно, согласен.
2020 November 21
AL
Загугли Rich Hillard architecture description 42010
AL
А вообще арх. описание это про обоснованное выполнение требований некоторым решением.
Его получатели это как минимум :
- Лиды разработки. Они должны дать оценку реализуемости и детализировать "дизайн" до конкретных задачек (может быть уже на разработку вместе с системным аналитиком).
- ПМ и ПО. Они там должны видеть, что бабки тратятся целенаправленно и с приемлемой эффективностью.
Его получатели это как минимум :
- Лиды разработки. Они должны дать оценку реализуемости и детализировать "дизайн" до конкретных задачек (может быть уже на разработку вместе с системным аналитиком).
- ПМ и ПО. Они там должны видеть, что бабки тратятся целенаправленно и с приемлемой эффективностью.
AL
А теперь обратите внимание, что я таки говорю "кому" и "зачем")
AL
Разработчик в таком описании обычно ищет неочевидные требования и отношения его юнита с окружающим контекстом. Ну чтоб два раза не переделывали дваа раза)
Так что если это там есть, то и хорошо)
Так что если это там есть, то и хорошо)
AP
Также хочу поделиться карточкой-опросником, которая может помочь восстановить дизайн решения. Буду рад обратной связи.
Хороший опросник, но всё же сервиса, а не всего решения. Из критики сходу - для rest для понимания, чего оно делает, ссылки на свагер зачастую недостаточно, потому что разрабы не заполняют описательную часть и верят, что имени метода достаточно
AP
Я б ещё явки добавил - где именно развёрнут, кто ответственный, вот это всё
GK
Хороший опросник, но всё же сервиса, а не всего решения. Из критики сходу - для rest для понимания, чего оно делает, ссылки на свагер зачастую недостаточно, потому что разрабы не заполняют описательную часть и верят, что имени метода достаточно
Да, для сервиса
Если получить описание сервисов, можно восстановить архитектуру решения
Если получить описание сервисов, можно восстановить архитектуру решения