Comments 13
Вы тут на статью расписали принцип "выкидывать старое постепенно когда на это есть время"
А ещё из личного опыта:
Раз:
- Зачем здесь второй базовый контроллер?
- Первый постепенно выкинем, будем использовать новый, и выпиливать старый пока время есть
- Да ну? Бред какой-то, надо всё сразу менять
Два:
- Зачем здесь второй базовый контроллер?
- Это паттерн "душитель"!
- Вау! Да, нужно работать по паттернам!
Мы как-то использовали паттерн "Душитель поверх душителя поверх душителя с сайдкаром и декораторами"
Только прочитал про ваш паттерн и попалась картинка на глаза :)
Мы раньше назывли это "прикрутить сбоку", а это теперь это оказывается паттерн 🤣
Какие вы прогрессивные!)
Да вообще нормально, что какие-то практики формируются естественным образом. Со временем их всё чаще начинают повторять. А потом кто-то замечает, что многие похожие решения отличаются надёжностью и устойчивостью, и называет это паттерном.
Лично мне раньше казалось, что "прикрутить сбоку" — это что-то на менеджерском и такие решения очень неправильные и некрасивые. А когда узнал про DWH, поразился красотой подхода и увидел в этом дополнительные плюшки, которые были бы недоступны в первоначальной парадигме.
Мне кажется, но тут термин "DWH" в той же степени как и "паттерн" - это все для красоты, вполне себе менеджерской.
Прикрутить сбоку сервис с БД (для приведенного кейса в статье требрвание к наличию DWH не очевидно, а не всякая БД есть DWH), реплицировать туда нужные данные, реализовать там какие-то фичи и соединить с основным сервисом через API - это можно назвать "прикрутить сбоку", или если очень хочется "сервисной архитектурой" (без приставки "микро"). Это как бы вполне обычная история.
Если говорить именно про паттерн Strangler - это подход именно к разделению существующего монолита на части. Со своей стратегией решения как выделить эту часть, и как интегрировать ее обратно в общую схему работы существующего решения. Там другой класс проблем решается, в отличие от создания нового компонента рядом с существующим.
Соглашусь, что классическое применение "душителя" — расщепление монолита. Но мне кажется ценным расширить понимание концепции до общей стратегии низкорискового роста. Ведь в основе — один и тот же принцип: строить новое, не ломая старое.
Вообще хотелось показать, что вариант "прикрутить сбоку" — это нормально. Его не нужно бояться. И не всегда стоит идти сложным маршрутом. На своей практике я часто вижу, как команды по умолчанию выбирают именно сложный путь, хотя для этого нет никаких объективных причин. Только миф о том, что "сделать по-нормальному" значит "переписать".
Этот посыл яростно плюсую.
Но тут, как и всегда, дорожка очень узкая - можно прийти к "зоопарку" хаотично налепленных копонентов, и систему становится сложно поддерживать и развивать. Конечно, можно сделать отсылку к здравому смыслу, но и он у все разный, и работает лучше всего "задним числом".
Мой поинт только в том, что на мой взгляд неправильно это называть паттерном "душитель". Скорее тут речь про более высокоуровневый подход к общей архитектуре - там где можно делать копоненты системы максимально независемыми. И применяя его нужно очень хорошо понимать, что это тоже не бесплатно.
Паттерн «Душитель». Как развивать сложные системы, не ломая старое