Об универсальности

О чём напоминают Вам слова «мы разрабатываем универсальное решение»? Мне они напоминают о сдвигаемых сроках, неожиданно обнаруживаемых ограничениях, и о чувстве горечи от костылей, которые выглядывают из недавно прекрасного решения.

Как возникают эти костыли?

Теория

Мы называем универсальным то, что подходит под широкий, но конечный спектр ситуаций. Ложка является универсальным предметом, если мы говорим о еде, но редко может заменить вилку. Универсальные клеи имеют на упаковках перечни материалов, которые они склеивают. Универсальный крем для обуви предназначен для обуви, нет широкого понятия "Универсальный крем".

Не бывает же просто универсального крема, не так ли?

Универсальность связана с конечным набором вариантов применения.

Слова «универсальность» и «ограниченность», кажущиеся антонимами, должны идти рука об руку не расставаясь ни на секунду — они не существуют друг без друга.

Причины костылей

Попытка унифицировать, зачастую, происходит из предположения, что текущее сложно-управляемое легаси избыточно сложно просто по историческим причинам. В причинах костылей, обычно, находится комплекс из:

  1. Отсутствия документированных бизнес-требований.
  2. Веры в чисто исторические причины.
  3. Ощущения, что те, кто делал это раньше «не догадались».
  4. Веры в единое универсальное решение.

Комплекс этот взаимо-поддерживающийся — одна вера или ощущение укрепляет другую. Список субъективный.

Я выскажусь по последнему пункту:

Вера в универсальное решение, которое когда-нибудь будет создано и не будет иметь ограничений — самообман.

Как видно из теории, универсальность без ограничений невозможна.

Вера в универсальное решение на высоком уровне может приводить к форсированию решений без должной оценки (вендор рассказывает про «low-code», а бизнес верит). На низком уровне — к игнорированию реальных кейсов на стадии проектирования. Выражается это в отсутствии исследования этих кейсов, в игнорировании мнений и сигналов, которые указывают на их существование.

Правильный подход

Иногда, что-то невозможно исследовать — компания велика, нет ни одного человека, который знал бы все процессы, люди ужасно заняты. В этом случае гарантирую, просто нельзя взять и заменить большой кусок системы без страданий и сюрпризов. Надо есть слона по частям.

Есть по частям означает — изменять отдельные, поддающиеся исследованию области в порядке их взаимозависимости.

Слон — есть по частям.

Слон — есть по частям.

Далее хардкор для архитекторов.

Переход от универсальности к модульности

Чтобы иметь известный набор ограничений, надо заранее ограничить какую-то область, чтобы она поддавалась исследованию и архитектурной проработке. Обозначим этот подход как модульность, где модулем может быть отдельный сервис или система.

Что не может быть модулем?

Модулем не может быть архитектурный блок высокого уровня, объединяющий вещи недоступные для исследования в рамках интервала времени, выделяемого на архитектурную проработку модуля.

Скажем, если Вы выделяете блок, содержащий все виды взаиморасчётов с партнёрами по десяткам разных видов партнёрства, надо понимать, что у каждого вида своя модель расчётов, свои входные параметры и источники. Быстро выявить и обобщить все модели расчётов в терминах бизнеса и приземлить на прикладную модель, реализуемую какой-то системой (если речь о решении вендора), невозможно.

Что может быть модулем?

В примере выше, хорошим модулем могла бы быть реализация одной модели расчётов, покрывающая какой-то один вид партнёрства.

Хорошим модулем могла бы быть система, куда выгружаются или инкрементально накапливаются результаты расчётов в формате, пригодном для передачи в другие системы. Почему? Формат диктуется ограниченным количеством целей применения, а ограниченность — условие возможной универсальности.

Модульность на уровне слоёв архитектуры

Пример

Хранилище данных как совокупность принципов и технологий можно считать модулем технологического уровня. Почему? Возможна архитектурная проработка принципов (адаптация, с учётом ресурсов соответствующей квалификации) за разумное время.

Можно реализовывать модели расчётов в хранилище данных по одной как модули прикладного уровня, изолируя одну модель от другой на уровне объектов БД, ETL-процедур и репозитория кода. По одной, значит каждую за разумное время.

Получается, модуль одного слоя архитектуры реализуется поверх модуля другого слоя архитектуры. Это хорошо.

Антипример

Не хорошо, когда в системе невозможно разделить модули прикладного уровня.

Например, если релиз каждого модуля затрагивает сборки, относящиеся ко всей системе, переиспользуются справочники в разных контекстах и общие функции, есть взаимное влияние «модулей» по нагрузкам — это означает, что система не позволяет реализовать модульность прикладного уровня — нижний архитектурный слой влияет на модульность верхнего.

Как раз такие не модульные системы предлагаются поставщиками как универсальные. Маркетинг.

Заключение

  1. Вера в универсальное решение, которое когда-нибудь будет создано и не будет иметь ограничений — самообман.
  2. Выбирайте для изменения отдельные, поддающиеся исследованию области в порядке взаимозависимости.
  3. Выбирайте решения технологического уровня, поддерживающие модульность прикладного.
  4. Не рассматривайте архитектурные блоки высокого уровня как целиковые единицы, закрываемые одной системой.

Настороженно относитесь к разговорам об универсальности.