При проектировании полного жизненного цикла Enterprise-приложений большое значение приобретает вопрос организации их доступа к данным. Тому есть ряд причин:

• ценовые или иные политики поставщиков хранилищ данных регулярно меняются, но предприятия, использующие данные хранилища, не всегда согласны с этими изменениями;
• с ростом самого предприятия и масштабов его ИТ-инфраструктуры существующие решения по хранению данных могут перестать удовлетворять его потребностям или финансовым возможностям;
• технологии хранения данных развиваются, появляются новые средства, предназначенные для решения специализированных задач;
• в рамках проектов Open Source вырастают дешевые или даже бесплатные альтернативы дорогим коммерческим решениям.

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

Проблему разделения бизнес-логики и работы с данными на уровне отдельного приложения решает широко известный и не раз описанный на «Хабрахабре» архитектурный шаблон Data Access Layer (DAL). Для того, чтобы этот шаблон можно было масштабировать до уровня всего предприятия, необходимо дополнить его рядом архитектурных принципов, которые рассматриваются в данной статье. Следование этим принципам позволит предприятию осуществлять контролируемую (управляемую) замену или добавлять технологии хранения данных в свою архитектуру ИТ.

Введение

До определенного момента своей жизни я ни о какой самоорганизации не задумывался. Все небольшое количество студенческих (аспирантских, junior-developer'ских) дел помещалось в голове, в нужный момент вспоминалось, а что не вспоминалось — тому не повезло. Женитьба, ремонт в квартире, рождение первенца, смена трех мест работы — все это удавалось худо-бедно удерживать в памяти. Но, как говорится, чем дальше в магазин, тем выше ставка по  кредиту. В какой-то момент у меня появилось ощущение, что я  постоянно занимаюсь «тушением пожаров» на работе, дома, в аспирантуре: провалил срок по рабочей задаче, не вспомнил о поездке к врачу с ребенком, дотянул до последнего с заказом билетов-отелей на летний отдых… О каких-нибудь хобби и получении удовольствия от жизни речи и вовсе не шло.

Рабочий процесс тоже походил на жонглирование горящими котятами: пишу код — всплывает уведомление Outlook — срочно бросаюсь читать и заниматься пришедшим письмом — звонит руководитель с напоминанием о поручении — все отложил, лихорадочно ищу письмо среди сотен похожих в папке «Входящие». Нашел — сделал, вернулся к коду с мыслью «Блин, чем же я тут занимался-то!?!?». О глубоком погружении в задачи можно забыть. И это притом, что в силу специфики компании, где я тогда трудился, у меня не было доступа в Интернет на рабочем месте Иначе, думаю, к коду я и не возвращался бы.