Ограниченные контексты, а не границы: почему микросервисы — неправильное название

Последнее десятилетие я проповедовал микросервисы, но ошибался. То, что мы называем микросервисами, обычно означает группу слабо связанных и независимо развертываемых модулей, что на самом деле является неправильным термином. Нам нужно сосредоточиться на истинных функциональных границах, а не на произвольных границах. Проблема начинается с того, как мы их строим. Мы рисуем линии, основываясь на техническом удобстве, организационных структурах или расплывчатых требованиях. Системы раздуваются из-за ненужной сложности. Ограниченные контексты отражают фактическую область. Возьмите приложение для электронной коммерции. Управление заказами, отслеживание запасов и обработка платежей выглядят как естественные точки разделения. Затем они начинают напрямую разговаривать друг с другом. Управление заказами вызывает инвентарь, который проверяет статус оплаты. Вы получаете распределенный монолит, который сложнее отлаживать, чем чистое однодвоичное приложение. Вот базовая настройка Go перед разделением: // монолит.го пакет основной импорт ( "сеть/http" "github.com/gorilla/mux" ) функция main() { r := mux.NewRouter() // Управление заказами r.HandleFunc("/orders", handleOrders).Methods("GET") // Отслеживание запасов r.HandleFunc("/inventory", handleInventory).Methods("GET") // Обработка платежей r.HandleFunc("/платеж", handlePayment).Me