В 2002 году внутри Amazon случилась штука, которая потом стала одной из причин, почему “просто интернет-магазин” превратился в гигантскую платформу. По легенде, Джефф Безос разослал по компании короткое правило (по сути — ультиматум): Любая команда обязана отдавать свои данные и функции через интерфейс. Никаких “давай мы просто напрямую залезем в вашу базу”. Никаких “мы вам скинем файлик” и “у нас исключение”. Только через интерфейс. Звучит скучно? Вот почему это не скучно. До этого в больших компаниях всё обычно устроено так: • один отдел делает фичу и “тихо” читает таблицы другого, • кто-то добавил поле — и половина сервисов падает, • никто не понимает, кто за что отвечает, • скорость разработки превращается в болотце. А “интерфейс-правило” насильно делает другое: • границы становятся чёткими (кто владеет чем), • ответственность становится конкретной (если интерфейс сломан — виновник виден), • масштабирование становится возможным (новая команда подключается по правилам, а не через дружбу). И главное — появляется эффект, который многие недооценивают: Когда ты заставляешь всё общаться через интерфейсы, ты случайно начинаешь строить платформу Потому что “интерфейс” — это уже почти продукт. Его можно улучшать, измерять, версионировать, делать стабильным. А дальше появляются сервисы, “магазин сервисов”, внутренние инструменты… и в какой-то момент это выстреливает наружу. Если совсем по-простому: они убрали хаос коммуникаций — и получили системный рост скорости. 3 вывода, которые можно забрать себе 1. Если у тебя 2+ человека в продукте — запрети “обходные пути”. То, что сегодня “быстро”, завтра — вечная боль. 2. Если хочешь стабильность — делай “один путь”, а не “сто вариантов”. Вариативность без правил = технический долг. 3. Если хочешь масштаб — сначала введи правила, потом добавляй фичи. Иначе ты просто ускоряешь хаос. @credorus