Comments 9
На счет использование fx, согласен, но думаю имеет место быть для небольших сервисов, хотя, тогда можно и вручную прокинуть. Так или иначе DI может решать свои проблемы, как и в других языках. Думаю это холиварный вопрос и мне не хватит экспертизы, чтобы в нем настаивать)
Тут я видимо назвал, как бы в c#, вырвалось)
Такое просто видел в различных проектах на github и посчитал нормальным, я так полагаю лучше контекст передавать именно в метод?
Вообще по структуре, когда на Go пробуешь писать, после более c# или java, то сложно вообще понять структуру проекта go или как-то ее объяснить, потому что она не выглядит хорошей или правильной. По-этому и хочется принести, что-то с собой из других языков)
Если микросервис в вашей системе нужно кодить на определённом языке и тем более по определённому шаблону, то это не микросервис.
change_my_mind.jpg
А что у вас есть микросервис?
Есть определенные договоренности внутри компании или команды, как писать код, что и как использовать или нет, что в этом плохого? Например, когда проекты от одной команды передают другой и получается каждый будет передавать свой поток сознания?
И в данном случае шаблон выступает, просто руководством или примером для тех, кто не видел и решает поизучать вопрос.
Микросервис это узкоспециализированный модуль, который пришлось разработать и запустить отдельно от других модулей.
Реализация микросервисов по шаблону решает некоторые вторичные проблемы (передача знаний и тому подобное), но уводит от решения первичных, ради которых вся эта хурма и затевалась.
И вообще. Если вы можете зафигачить всю систему однородными микросервисами, то обычным модульным монолитом вы её зафигачите быстрее/дешевле минимум в π раз.
Шаблоны в микросервисной архитектуре нужны между сервисами (интерфейсы и потоки данных), а не для каждого из них.
Не вижу связи между шаблоном построения конкретного сервиса с точки зрения организации кода и интерфейсов и потоков данных. При наличии первого, автоматически не отменяется второе.
А про модульный монолит тоже странно, если просто микросервисы деплоятся из одного репозитория, то это не модульный монолит, а если вы имеете ввиду, что хранить все в одном проекте, то это странная идея и несет большое количество проблем, ведь микросервисов в компании может быть много
А на сколько верна практика что покупка книги находится в сущностях-контролере-урле 'book', а не выделяется в отдельный микросервис который занимается продажами расчетами оплатой?
Смотря какое решение мы собираешься реализовывать.
В данном случае как тестовое задание не вижу смысле прям в отдельный сервис выносить.
А по хорошему на микросервисы разбивают по разным причинам, если нет потребности и имеется, только домен с которым мы работаем, как например небольшой магазин книг, не вижу смысла делать отдельно.
Шаблон Go-микросервиса для начинающих от .NET разработчика. Часть 2