avl (avl) wrote,
avl
avl

16. Однообразия может и не быть.

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

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

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

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

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

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

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know, Программирование, Развитие
Subscribe

  • Один день на яхте

    Давно, очень давно хотелось оказаться на яхте. И вот наконец удалось реализовать мечту, пока что на 1 день. Главное — что оказалось, что никого из…

  • Подарок на 8 марта :)

    Фирма удивила, подарив 8 марта ВСЕМ сотрудникам смарт-часы от неизвестного производителя с нанесенным своим логотипом :) Да, в Словении 8 марта -…

  • Подводная лодка

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments