Комментарии 3
Спасибо за статью и за иллюстрации, было интересно посмотреть на нреальном примере, особенно понравилось что при декомпозиции системы опирались на понятия DDD и onion architecutre, а не просто херачили на куски. Мне лично кажется, что если грамотно соблюдать границы контектсов, можно и монолит сделать достаточно гибким, слобосвязанным и расширяемым, без необходимости вынесения частей в отдельные приложения.
Ну и понравилось, что в конце не забыли подитожить, что микросеврисы это «дорого», этого понимания имхо не хватает многим людям, не понимающим оверхед такого подхода.
Ну и понравилось, что в конце не забыли подитожить, что микросеврисы это «дорого», этого понимания имхо не хватает многим людям, не понимающим оверхед такого подхода.
А расскажите, как проихсожит релиз микросервиса, при мажорных изменениях в апи, ломающих обратную совместимоть? Вы держите рабочими все версии сервиса, давай клиенту возможность обратиться к нужной(типа ordess.corp/4.12/create, ordess.corp/3.12/create и т.д) или это решается как то иначе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переход от монолита к микросервисам: история и практика