Как правильно создается и поддерживается архитектура для микро сервисов?

Question

[MishaXXL]

Если я правильно понял, то в микро сервисной архитектуре у каждого сервиса должен быть свой репозиторий
Но как быть с задачами, когда она касается клиентского сервиса и одного из серверов?
В данном случае получается у нас нужно создавать две одинаковых ветки в репозиториях client и server?
Как правильно подходить к решению подобных задач?

Comments

[Everything_is_bad]

две одинаковых ветки в репозиториях client и server

ух уровень понимания, забей, научись сначала правильно делать монолиты, будет опыт, разберешься и с микросервисами

Answer 1

[Vitaly Karasik]

Так же как и в любой клиент/сервер архитектуре, я не вижу разницы для микросервисов.
Должен быть протокол для API. Если в нем нужны изменения, то имплементировать их на стороне сервера и клиента так, чтобы обновления не сломали ничего.

Answer 2

[Василий Банников]

Если я правильно понял, то в микро сервисной архитектуре у каждого сервиса должен быть свой репозиторий

Нет, не должен. Код может быть организован так, как это будет удобнее для людей, которые будут эти микросервисы поддерживать.

Но как быть с задачами, когда она касается клиентского сервиса и одного из серверов?

Это две разные задачи: одна на сервер и одна на клиент.
API должен быть спроектирован так, чтобы сервер был обратно совместим с клиентом.
Если всё-таки клиент и сервер должны будут обновляться одновременно, то тогда нужно координировать релизы - опять же к веткам в репозитории никакого отношения не имеет.