Рішень може бути кілька

Кейт Брайтуейт

Одна модель даних, один Формат повідомлень, один транспортний механізм (і взагалі рівно один основний архітектурний компонент, політика, принцип і т п) не може однаково добре обслуговувати всі аспекти діяльності комерційної організації Схоже, цей факт є нескінченним джерелом подиву і засмучення для творців систем У той же час це абсолютно природно: якщо вже організація (слово «Організація» тут підкреслено жирною червоною лінією) досить велика, щоб хвилюватися про те, як кілька різних таблиць рахунків вплинуть на систему в наступному десятилітті, вона напевно занадто велика і неоднорідна, щоб можна було обійтися однією таблицею рахунків

У технічній області однаковість можна ввести примусово І для нас це досить зручно Однак у сфері бізнесу у гру вривається суперечливий, багатогранний, неформальний, клопіткий реальний світ Що ще гірше, бізнесу доводиться мати справу навіть не з реальним світом, а з думками людей про тих чи інших аспектах ситуацій в тих чи інших частинах цього світу Можна, звичайно, спробувати поставитися до цієї сфери як до технічної та впровадити єдине рішення в наказовому порядку Однак реальність неформально визначається як «те, що не зникає, коли в нього перестаєш вірити» (Філіп К Дік), і в міру розвитку бізнесу проблеми завжди повертаються Так виникають команди, що займаються корпоративними даними і тому подібним, які витрачають все своє (дуже дороге) час на приборкання екзистенціального жаху допомогою жонглювання DTD1

DTD (Document Type Definition) – визначення типу документа – преамбула документа, що визначає в мовах структурної розмітки даних (SGML, XML) склад і структуру документа – Прямуючи ред

Час відгуку подібних систем зазвичай виявляється незадовільним з точки зору замовника

Чому б не прийняти реальність непослідовного світу і не допустити існування кількох неузгоджених, перекриваються уявлень, служб, рішень Так, технічний спеціаліст в кожному з нас, почувши таку пропозицію, зіщулюється від жаху Ми відразу уявляємо собі кошмарні сценарії: неузгоджені поновлення, зайві витрати на супровід, клубки залежностей, якими доводиться керувати .. Але давайте запозичимо корисний досвід зі світу зберігання даних Вітрини даних (data marts) часто денормалізуются (в реляційному сенсі), в них довільно змішуються імпортовані і обчислені значення, а представлення даних сильно відрізняються від уявлень даних у вихідних базах даних І при цьому від наявності у вітрини даних нефункціональних властивостей ніякої катастрофи не відбувається На кордоні двох абсолютно різних світів – як правило, операцій з даними і аналітичної обробки з характерними для них відмінностями в частоті відновлення і вибірки, в пропускної здатності, в періодичності змін структури і, можливо, навіть в обсягах – знаходиться ETL-процес[6] У цьому ключ до задачі: досить сильні відмінності в нефункціональних властивостях системи формують кордон, через яку вдається організувати практичне управління неузгодженими уявленнями

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

Біографія автора наведена на стор 35

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*