(В оригинале There Can be More than One)

Кажется, что архитекторов никогда не перестанет удивлять тот факт, что не существует единственной модели, единственного формата данных, единственного протокола передачи – фактически, любого крупного архитектурного компонента, политики или положения, способных полностью подойти для любой ситуации в бизнесе. Конечно же, для достаточно крупного энтерпрайза, которому нужно беспокоиться о том, сколько различных таблиц “Account” понадобится в следующей декаде, одной таблицы “Account” для всего будет недостаточно.

В технических областях мы все можем привести к одинаковости. Для нас – очень удобно. Однако бизнес имеет дело с неупорядоченным, множественным, запутанным и неопределенным миром. Более того, бизнес имеет дело даже не с «миром», а с мнениями людей о том или ином аспекте этого мира. Одно из решений – считать, что мы имеем дело с технической областью, и принудительно применить универсальное решение. Однако реальность – такая штука, которая продолжает существовать, даже если вы не верите в нее. И сложность все равно появляется по мере эволюции бизнеса. В результате появляются энтерпрайз команды, тратящие свое очень недешевое время на попытки побороть страхи разговорами о DTD. А заказчики, оплачивающие это, склоняются в результате к тому, что получаемый результат далек от совершенства.

Почему же не принять реальность этого беспорядочного мира и не разрешить множественные, противоречивые, пересекающиеся представления, сервисы и решения? С технической точки зрения это может звучать просто ужасно. Только представьте: несогласующиеся обновления, перерасход ресурсов на техподдержку, зависимости, напоминающие тарелку со спагетти, которые надо держать под контролем, и прочие подобные вещи. Однако давайте посмотрим на пример из мира информационных хранилищ. Схемы данных часто ненормализованы, исходные и вычисленные данные смешиваются друг с другом, структуры данных и представляющих и таблиц сильно различаются. И небеса не падают. ETL процесс находится на границе двух различных миров, транзакций и анализа. Эти миры различаются частотой изменения, пропускной способностью, частотой изменения дизайна и возможно также сильно отличаются в объеме. И это здесь – ключевой момент: сильно отличающиеся нефункциональные свойства подсистемы создают границу, на которой и становится возможным управлять противоречивыми представлениями.

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

Автор оригинала - Keith Braithwaite