Comments 19
а эти новые DTO никто не использовал? 0_о
Вы исходите из посыла, что это не нормально. А почему это не нормально? Может у вас просто медленные лошади?
Ну так решение очевидно - вынести из common-dto все специфические (не общие) объекты и поместить их на соответствующий нижележащий уровень.
Похоже на маркер, но скорее организации разработки, чем архитектуры - в микросервисах любой общий код становится проблемой на всех уровнях, в том числе на уровне сборки. Просто кататься на микросервисах санках хочется, а таскать их - нет, ничего нового
А как это оно в у вас было организовано раньше, если разные репозитории у сервисов, а был общий, на который остальные завязаны и он всё время меняется? Как это работало-то? Каждая группа туда коммиты пачками кидала и непрерывно мерджила?!
У вас изначально какая-то лють получается. Тут не репозитории нужно менять, а срочно архитектуру в порядок приводить. Желательно даже до того, как в монорпозиторий объединять.
Вопрос к знатокам. Возможно, ночь и я туплю, но не могу сообразить.
Допустим, в этом случае была бы более-менее нормальная архитектура. Допустим, что по какой-то причине все объединено в монорепозиторий. А как разработка-то теперь ведётся? Все имеют доступ к общему репозиторию и выкачивают все изменения? Каждый комит в каждом сервисе будет комитом в общий репозиторий? Куча веток с фичами и сервисами? Тестировать только всё в сборе?
Монорепа хороша, когда меняются сразу несколько компонентов. Например, меняется апи, то можно в отдной ветке править и тестировать сразу и клиент, и сервер, а не как в разных репах: «Дим, а Дим, а какая ветка фронта соответствует бэку?». Монорепы меня смущают, что в vs code в devcontainers перестает работать git :(
Просто нужно помнить что микросервисы это организационный, а не технический паттерн. Можно считать что один репозиторий – одна команда. Если до этого это команда зачем-то комитила код в больше чем один репозиторий на постоянной основе, т.е практически любое изменение превращалось в несколько MR/PR в разные репозитории (кейс команды куда я пришел), то "монорепо" правильное решение, от ревью до сборки все упрощается. А хороший билд тул с кешированием (gradle в нашем случае) решает проблему времени сборки.
Единственное, что в итоге в команде осталось разделено на отдельные репозитории – фронтенд от бекенда и несколько стабильных библиотек.
микросервисы это организационный, а не технический паттерн
Сильное утверждение.
Все технологии необходимые для микросервисов были еще в эпоху расцвета SOA, от того что стек стал моднее SOA не мог же стать микросервисами?
У вас что-то с пунктуацией - тяжело понять что вы имели в виду.
В любом случае, модность или не модность чего-то никак не отменяет того, что микросервисы решают некоторые технические проблемы: например, горизонтальное масштабирование отдельных частей системы. Монолит тоже можно горизонтально маштабировать, но это добавляет дополнительные расходы по пямяти и времени старта, как минимум.
Может им монолит попробовать? Знаете как удобно когда можно сбилдить все одной командой. А запустить локально одним кликом на кнопку ран в ide. А как дебажить будет приятно, прошел по шагам топ-топ-топ дебагером - багу нашел. А коммуникации какие надежные внутри процесса - вызвал функцию, а она взялась и вызвалась, и никак иначе.
Если я правильно понимаю, то большинство dto общие для двух микросервисов.
Да, тут либо большая свалка dto, одно на всех, либо на каждую пару сервисов свой dto проект, либо зависимость клиента от сервера.
Два последних метода могут привести к аду зависимостей. А как лучше - тут общих решений нет.
Сборка в Gitlab как маркер здоровья архитектуры