Size: a a a

Software Design/Architecture/Zen

2021 February 10

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Обсуждать, менять и версионировать можно и не в отдельном репозитории. На вкус и цвет
Если монолит, то да. Если репы приватные отдельные, то возникает вопрос кто кого к себе будет впускать
источник

k

knopkod4v in Software Design/Architecture/Zen
Dmitry Eliseev
Команда A и команда B делают два сервиса, которые будут взаимодействовать по API. И они делают репозиторий для спеки.
ну начинается опять "взаимодействовать по API"
источник

MG

Max Grom in Software Design/Architecture/Zen
Что значит кто кого будет впускать? Описание интерфейса взаимодействия с сервисом можно положить рядом, можно не ложить рядом. Вообще без разницы приватное там что-то или нет
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Обсуждать, менять и версионировать можно и не в отдельном репозитории. На вкус и цвет
А consumer driven вообще предполагает, что спекой владеет потребитель
источник

MG

Max Grom in Software Design/Architecture/Zen
Есть контракт потребителя и есть контракт поставщика. Не совсем понимаю что значит “спекой владеет потребитель”
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Есть контракт потребителя и есть контракт поставщика. Не совсем понимаю что значит “спекой владеет потребитель”
Два доклада выше об этом
источник

MG

Max Grom in Software Design/Architecture/Zen
Я понимаю о чём доклады выше. Мне непонятно почему важно монолит ли у нас, приватный ли это репник, кто кого куда пускает и т.д. Это всё не имеет значения в вопросе о том, где хранить спецификацию
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Я понимаю о чём доклады выше. Мне непонятно почему важно монолит ли у нас, приватный ли это репник, кто кого куда пускает и т.д. Это всё не имеет значения в вопросе о том, где хранить спецификацию
Тогда о чём спор? Если пофиг где хранить спеку, то и храним пофиг где. Если же спеку придумывает сервис, то логично хранить рядом с сервисом. Если же её придумывают потребители, то логично спеку хранить у потребителя.
источник

MG

Max Grom in Software Design/Architecture/Zen
Совершенно верно. Просто ваша фраза про “если спека вынесена в отдельный репозиторий, то её можно обсуждать, менять и версионировать отдельно” - прозвучала как поинт за отдельное хранение. Я лишь указал, что всё то же самое можно делать и без привязки к “вынесению”
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Совершенно верно. Просто ваша фраза про “если спека вынесена в отдельный репозиторий, то её можно обсуждать, менять и версионировать отдельно” - прозвучала как поинт за отдельное хранение. Я лишь указал, что всё то же самое можно делать и без привязки к “вынесению”
Я про то, что если спека лежит в чужом приватном репозитории проекта, то без доступа к этому репозиторию её в issues не пообсуждаешь и pull request не кинешь.

А если спека лежит в отдельном от проекта общедоступном репозитории, то полная свобода действий.
источник

MG

Max Grom in Software Design/Architecture/Zen
Если спека в чужом приватном репозитории - то можно а) попросить доступ или б) попросить предоставить спеку без доступа. Упомянутый автором вопроса OAS имеет имплементации позволяющие предоставлять спецификацию, которая будет продолжать лежать в чужих приватных репниках 🤷 Вы почему-то переводите проблемы коммуникации в вопросы хранения
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Я понимаю о чём доклады выше. Мне непонятно почему важно монолит ли у нас, приватный ли это репник, кто кого куда пускает и т.д. Это всё не имеет значения в вопросе о том, где хранить спецификацию
Если понимаете, о чём доклады выше, то значит понимаете, что значит “спекой владеет потребитель”
источник

MG

Max Grom in Software Design/Architecture/Zen
Вопрос владения не относится к вопросу размещения. Причём тут доклады??
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Вопрос владения не относится к вопросу размещения. Причём тут доклады??
Как это "не относится"? Если спеку делает потребитель, то он ей и владеет в своей репе.
источник

MG

Max Grom in Software Design/Architecture/Zen
Потребитель делает контрак потребителя. Пусть хранит его хоть на бумаге. Как это относится к вопросу автора о том где ему хранить спеку?
источник

MG

Max Grom in Software Design/Architecture/Zen
Если потребитель хочет изменить свой контракт - это вопрос коммуникации а не хранения
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Потребитель делает контрак потребителя. Пусть хранит его хоть на бумаге. Как это относится к вопросу автора о том где ему хранить спеку?
Джентльмен спросил, есть ли смысл выносить отдельно спеку. Я сказал, что есть смысл, если хочется обсуждать, модифицировать и версионировать спеку отдельно.
источник

MG

Max Grom in Software Design/Architecture/Zen
А я сказал, что это всё можно делать и не вынося 🤷
источник

MG

Max Grom in Software Design/Architecture/Zen
Ваш кейс сильно зависит от наличия в принципе подхода, который описанный в докладах выше. Но кейс таких условий не подразумевает
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Max Grom
Если спека в чужом приватном репозитории - то можно а) попросить доступ или б) попросить предоставить спеку без доступа. Упомянутый автором вопроса OAS имеет имплементации позволяющие предоставлять спецификацию, которая будет продолжать лежать в чужих приватных репниках 🤷 Вы почему-то переводите проблемы коммуникации в вопросы хранения
б) "Если хотите получить актуальную спеку, но напишите бабе Маше в аську. Она вернётся из продмага и вынесет вам на дискете"

К чёрту такие коммуникации.
источник