Comments 5
Проголосовал "за" в опросе, но понимаю, что есть разные уровни этой самой культуры, так что "за" будет с много большим перевесом. PS Про кассира улыбнуло, зачётно.
После GatewayAPI можно выделить слой «бизнес-сервисов» описывающих логику сущностей по примеру предложенных в статье, а за ними можно выделить слой микро-сервисов, реализующих конкретную задачу. Но это так, чисто для примера развития…
А вообще оставлю это здесь: https://docs.microsoft.com/ru-ru/dotnet/architecture/microservices/
объясните мне это предложение:
это перевод через гугл транслейт?
для чего?
Фактически, эта практика взята из Open Source сообщества — выживают и наиболее популярны лучшие решения в своей области.
это перевод через гугл транслейт?
В контексте предложенной архитектуры сразу становится ясно, что для быстрой продуктовой разработки крайне необходимы готовые библиотеки для.
для чего?
объясните мне это предложение:
Фактически, эта практика взята из Open Source сообщества — выживают и наиболее популярны лучшие решения в своей области.
Речь о том, что в Open Source для решения одной и той же задачи на одном стеке обычно существует несколько решений. Однако, обычно есть решение, наиболее популярное у сообщества. Внутри компании организовать тоже самое, но в меньшем масштабе, мне кажется, хорошая идея.Наличие большого количества готовых инструментов внутри компании также является благом.
В контексте предложенной архитектуры сразу становится ясно, что для быстрой продуктовой разработки крайне необходимы готовые библиотеки для.
для чего?
Поправил, «для» в конце не нужно.
Sign up to leave a comment.
Сервисы, микросервисы и пакетно-ориентированное программирование