Наш коллега Алексей Андреев (Леруа, Лэтуаль и другой enterprise) в своем канале разобрал статью Криса Питчманна Disposable Software Is the Future. Мы прочитали оригинал и хотим добавить свои пять копеек, потому что автор, сам того не зная, описал принципы, на которых построена Ensi.

1. Делить систему по бизнес-возможностям, а не по техническим слоям. Сервисы Ensi построены вокруг доменов ритейла: каталог, заказы, клиенты и прочее.

2. Отделять интерфейс от реализации и версионировать контракты. Каждый сервис Ensi общается с внешним миром через версионированный API. Реализацию можно переписать, но сам контракт останется.

3. Не использовать общую базу как способ интеграции. «A database is not an API». У каждого сервиса Ensi своя база, интеграция идет через API и события.

4. Проектировать с учетом заменяемости любых компонентов. Это, пожалуй, главное. Ensi — open source с сервисной архитектурой: любой сервис можно доработать или заменить без разрешения вендора и переписывания всего остального. Мы называем этот подход эволюционной архитектурой: IT меняется вслед за бизнесом, а не диктует ему, как жить. Разные части системы меняются с разной скоростью. Интерфейсы, промо-логика, AI-фичи и интеграции с вендорами меняются часто, а ядро домена, финансовые записи, модель клиента стабильны. Архитектура должна защищать стабильное и позволять заменять волатильное.

Еще мысли из статьи, которые мы повторяем клиентам постоянно:

5. Полная замена системы — один из самых опасных паттернов в enterprise, потому что новый проект устаревает раньше, чем запускается. Подход Ensi подразумевает уважительное отношение к legacy и позволяет реализовать разные стратегии переезда на новые решения (статья об этом)

6. Про AI: возможности моделей нельзя вшивать в ядро бизнес-логики. Только подключать как сменный модуль через стабильный контракт, потому что провайдер и модель поменяются, а интерфейс останется. «The interface is the asset. The implementation is replaceable». По этой схеме сервисы Ensi Cloud (поиск, рекомендации, генерация контента) подключаются к (любой) платформе.

7. И финальный вывод статьи, который стоит процитировать дословно: самая большая архитектурная ошибка — не выбор неправильного фреймворка, языка или облака. Самая большая ошибка — построить систему, которую нельзя изменить.

👉 Читать оригинал статьи