Еволюціонує архітектура і стихійне проектування: Еволюція архітектури

1. Серія контенту:
2. Цей контент є частиною серії: Еволюціонує архітектура і стихійне проектування
3. Про цю серії
4. Відмінності архітектури від дизайну
5. Малюнок 1. Відмінності між архітектурою та дизайном
6. Малюнок 2. Використання класу ActionForm в Struts
7. Малюнок 3. Ослаблення зв'язків між класами предметної області та інфраструктурою за допомогою композиції
8. Деякі архітектурні міркування
9. Політика проектування інфраструктури
10. Створювати або купувати
11. Уникайте пасток
12. Малюнок 4. Діаграма відповіді на питання "купувати або створювати?".
13. Типізація в архітектурі
14. Малюнок 5. Взаємодія між додатками в стилі RPC
15. Малюнок 6. Вільна типізація кінцевих точок
16. Малюнок 7. Аналіз вмісту всередині точки доступу для визначення його типів даних
17. Висновок
18. Ресурси для скачування

Еволюціонує архітектура і стихійне проектування

Міркування на тему проектування архітектури за методикою Agile і підходи до реалізації

Серія контенту:

Цей контент є частиною # з серії # статей: Еволюціонує архітектура і стихійне проектування

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Эволюционирующая+архитектура+и+стихийное+проектирование

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Еволюціонує архітектура і стихійне проектування

Слідкуйте за виходом нових статей цієї серії.

Деякий час назад в першій статті цієї серії було запропоновано кілька визначень поняття "архітектура" в контексті розробки програмного забезпечення. Однак якщо ви прочитали всі статті серії (до речі, спасибі вам за це), ви напевно помітили, що основна увага приділялася дизайну додатків. Це було зроблено з кількох причин. По-перше, багато визначення архітектури давно відомі в середовищі розробників (правда, невідомо, добре це чи погано), в той час як стихійне проектування отримало набагато меншу популярність. По-друге, багато проблем дизайну мають конкретні, менш залежні від контексту рішення. При цьому архітектура завжди так чи інакше пов'язана з фізичної або логічної інфраструктурою компанії, тому її важко обговорювати поза цим контекстом.

Про цю серії

В цій серії пропонується нова точка зору на часто обговорювані, але не мають однозначних визначень поняття архітектури та дизайну. У статтях серії Ніл Форд на конкретних прикладах пояснює фундаментальні принципи методології Agile, пов'язані з еволюціонує архітектурою і стихійним дизайном додатків. Одним з таких принципів є відкладання важливих рішень, що стосуються архітектури та дизайну, до останнього слушного моменту, що дозволяє уникнути краху проектів через необов'язкового надмірного ускладнення.

Ця стаття повинна заповнити прогалину, пов'язаний з недостатньою кількістю матеріалів про архітектуру Agile. У ній розповідається про відмінності архітектури від дизайну і описуються деякі загальні міркування розробки архітектури. Крім того, в статті розглядаються аспекти проектування сервіс-орієнтованої архітектури (SOA) на основі методології Agile, а також обговорюються питання управління версіями.

Відмінності архітектури від дизайну

На мою думку, краще визначення архітектури дав Мартін Фаулер (Martin Fowler) в одній з наших бесід. Воно звучить наступним чином:

Архітектура - це те, що важко змінити на пізніх стадіях розробки. Тому її має бути якомога менше.

Один із способів візуалізації зв'язку між архітектурою та дизайном представлений на малюнку 1.

Малюнок 1. Відмінності між архітектурою та дизайном

Архітектура програми, показана у вигляді сірих кубиків на малюнку 1 , Являє собою фундамент, на який спираються всі інші компоненти системи, в тому числі елементи дизайну, показані у вигляді червоних кубиків. Архітектурні компоненти, як правило, важко пересувати з місця на місце, оскільки при цьому доводиться рухати все що лежать вище блоки, які будуть порушені змінами в фундаменті. В цьому і полягає основна відмінність архітектури від дизайну. Наприклад, Web-інфраструктура, що використовується при створенні Web-додатки, є елементом архітектури, оскільки її складно змінити. При цьому ви можете застосовувати різні підходи до проектування дизайну в рамках однієї архітектури, що дозволяють досягти різні цілі. Це говорить про те, що більшість прийомів проектування (design patterns) відноситься саме до дизайну, а не до архітектури.

Наслідком визначення архітектури, даного Фаулером, є необхідність конструювання компонентів архітектури таким чином, щоб їх можна було замінити при гострій необхідності. Але як це зробити? Розглянемо приклад.

Безліч інфраструктур пропонують розробникам використовувати власні класи замість класів загального призначення, що входять в JDK або в бібліотеки, розроблені відкритими інститутами по стандартизації (наприклад, OASIS). Це приклад фатальною пов'язаності між компонентами: піддавшись на подібні пропозиції, ви назавжди опинитеся прив'язаними до даної конкретної інфраструктурі. Подібні інфраструктури, як правило, набагато легше використовувати, якщо працювати безпосередньо з їх класами. Чудовим прикладом може служити інфраструктура Apache Struts (див. Розділ ресурси ).

Класи всередині вашого застосування, що реалізують бізнес-правила і іншу логіку, називаються класами предметної області. Вони відповідають за обробку даних, що відносяться до галузі застосування. Struts надає зручний клас ActionForm, що виконує допоміжні функції. Якщо ви успадковуєте свої класи предметної області від ActionForm, то починається справжнє диво: поля форм автоматично заповнюються параметрами запитів, дані автоматично валідіруются як в шарі клієнта, так і сервера, і т.д. Все, що для цього потрібно - це зробити ваш клас спадкоємцем ActionForm, як показано на малюнку 2.

Малюнок 2. Використання класу ActionForm в Struts

Як видно з малюнка 2 , Модель додатка включає ваш клас предметної області. Він успадковує клас ActionForm, що є частиною Struts, що ускладнює подальше зміна структури. Наприклад, якщо в майбутньому ви вирішите, що клас ScheduleItem повинен також використовуватися в додатку на основі Swing, то виникнуть серйозні проблеми. Перед вами постане вибір меншого з двох зол: перенести Struts в Swing-додаток, але не використовувати його, або відокремити ваше додаток від Struts.

Більш правильне проектування полягає в використанні композиції замість наслідування (рисунок 3).

Малюнок 3. Ослаблення зв'язків між класами предметної області та інфраструктурою за допомогою композиції

У цій версії архітектури клас предметної області (показаний жовтим кольором) містить посилання на об'єкт, який реалізує інтерфейс, який визначає семантику елемента розкладу (schedule item). Класи ScheduleItem і ScheduleItemForm реалізують цей інтерфейс, що забезпечує сумісність їх семантики у всіх випадках. При цьому ScheduleItemForm в свою чергу містить посилання на бізнес-клас ScheduleItem, а все його методи для читання і зміни властивостей делегують виклики відповідним методом класу ScheduleItemForm. Це дозволяє використовувати всі переваги Struts, в той же час уникаючи надмірної залежності від цієї інфраструктури.

Таким чином, основне правило звучить наступним чином: інфраструктура цілком може посилатися на класи вашої програми, але неприпустимо, щоб класи предметної області безпосередньо використовували класи інфраструктури. Дотримуючись цього принципу, ви зможете підтримувати кордон між вашим додатком і інфраструктурою, що полегшує подальші зміни в дизайні і архітектурі. Іноді це вимагає деяких зусиль, але зате в результаті вийде більш гнучке додаток. Struts - це не єдина інфраструктура, спокушати розробників подібним чином. Практично будь-яка інфраструктура надає допоміжні класи, що обмежують гнучкість вашого застосування. Якщо вам доводиться імпортувати пакети, що відносяться до інфраструктури або іншим спеціалізованим бібліотекам, то, ймовірно, в цей момент ви створюєте всі умови для головного болю надалі.

Деякі архітектурні міркування

При створенні корпоративних додатків доводиться вирішувати безліч архітектурних проблем крім безпосередньо випливають з її визначення. Нижче ми розглянемо кілька методик Agile для подолання деяких з подібних складнощів.

Політика проектування інфраструктури

Корпоративна політика стає одним з перших неприємних відкриттів для новоспечених архітекторів. Архітектор, як правило, є найвищою технічної посадою в компанії, тому вам доведеться пояснювати і відстоювати всі рішення, прийняті всередині ІТ-відділу (причому як вдалі, так і немає). Іншими словами, ви будете брати на себе відповідальність за всі помилки, не отримуючи заохочення за досягнення. Деякі початківці архітектори намагаються ігнорувати цю проблему. Однак це відмінно працює, поки ви займаєтеся розробкою продуктів, але не архітектором.

Запам'ятайте, що спілкування відіграє важливішу роль у більшості проектів з розробки ПЗ, ніж технології. Якщо вам доводилося брати участь в провалився проект, задумайтеся над тим, чому він провалився. Це сталося через технічні проблем або через проблеми з взаємодією всередині команди? Як правило, основна причина лежить в площині взаємодії. Технічні проблеми завжди мають рішення, нехай і не завжди прості. Соціальні проблеми часто виявляються більш неприємними і складними в дозволі. На цю тему є відмінна цитата з книги "Людський фактор" (див. Розділ ресурси ):

Проблема завжди в людях.

Політика впливатиме навіть на самі, здавалося б, банальні технічні рішення, особливо якщо на вас лежатиме відповідальність за схвалення закупівель матеріального забезпечення (з іншого боку, вам може пощастити пограти в гольф за рахунок постачальників обладнання). Не забувайте, що як архітектор, ви не тільки повинні приймати важливі рішення, а й відстоювати їх перед керівництвом. Вам має бути спілкуватися з людьми, у яких є власні плани, які мають сенс виключно в умовах суворої корпоративної політики. Головне при цьому не впадати у відчай і чітко усвідомлювати, чому ви прийняли те чи інше рішення.

Створювати або купувати

Один з найбільш поширених питань, що виникають у всіх великих компаніях, полягає в тому, чи слід купувати готове комерційне програмне забезпечення (Commercial Off-The-Shelf Software - COTS) або створювати його самостійно, враховуючи поточні вимоги. Причини, за якими це питання піднімається, абсолютно очевидні: якщо компанія може знайти готове додаток, що виконує в точності необхідні функції, то воно заощадить час і гроші. На жаль, з огляду на подібні міркування, безліч компаній-розробників випускають ПО, яке можна налаштовувати багатьма способами, якщо воно не повністю задовольняє вимогам. Вони намагаються створювати ПО найбільш загального призначення, щоб продавати його як можна більшій кількості клієнтів. Однак чим менше спеціалізованим є ПО, тим більше його доводиться налаштовувати. Для цих цілей існує ціла армія консультантів, які можуть працювати роками, конфігуруємо систему під конкретного замовника.

Питання, чи варто купувати COTS, на практиці зводиться до іншого питання: яке значення мають бізнес-процеси, автоматизує цим ПО, - стратегічне або допоміжне? Купівля COTS має сенс у другому випадку, зокрема, для автоматизації кадрової, фінансової або іншої господарської діяльності. У свою чергу стратегічне ПО забезпечує конкурентну перевагу на ринку, і його не слід упускати на користь іншої компанії.

Уникайте пасток

Пам'ятайте: не всі бізнес-процеси можуть бути реалізовані в стандартних продуктах, а ті, які можуть, розрізняються в різних компаніях. Ставтеся з підозрою до компаній-розробників, які запевняють, що автоматизували ваші бізнес-процеси. Якщо вони дійсно це зробили, то можете бути впевнені, що вони вже продають свої технології вашим конкурентам.

Діаграма на малюнку 4 повинна допомогти вам у прийнятті рішення на користь покупки і створення програмного забезпечення.

Малюнок 4. Діаграма відповіді на питання "купувати або створювати?".

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

У другу чергу ви повинні визначити, чи здатний продукт відразу ж приносити користь компанії. При покупці ПО компанії часто припускаються помилки через неправильне уявлення про те, скільки часу займе його налаштування під потреби конкретного бізнес-процесу. Більш того, більшість компаній помиляються у своїх оцінках на порядок. Чим більше треба налаштовувати в продукті, тим більше це займе часу. При цьому можлива ще більш складна ситуація, при якій компанії дозволяють змінювати власні бізнес-процеси, щоб вони відповідали можливостям ПО. Це серйозна помилка, оскільки ваші процеси повинні обов'язково відрізнятися від аналогічних процесів у ваших конкурентів.

Далі ви повинні вирішити, чи є дане ПО розширюваним (не слід плутати розширюваність і зручні налаштування). Розширювані системи надають чітко визначені можливості по додаванню нової функціональності без необхідності зміни існуючого коду. Подібні точки розширення включають в себе ясно описані API, виклики SOAP тощо. При цьому настраиваемость має на увазі необхідність усіляких "трюків", щоб змусити систему виконувати необхідні функції. Наприклад, вам може знадобитися розпакувати WAR-файл, щоб замінити в ньому файл index.gif на іншу картинку (яка також зобов'язана називатися index.gif). Це саме настройка, а не розширення. Запитайте себе, чи зможуть ваші зміни успішно пережити перехід на нову версію ПО. Якщо так, то ви змогли розширити систему, а в іншому випадку - всього лише змінили її. Налаштування призводять до перешкод до оновлення ПЗ, оскільки ви розумієте, наскільки важко буде перенести зміни до нової версії. У підсумку в один прекрасний день може виявитися, що ви використовуєте систему, яка на п'ять версій старше поточного релізу а, отже, ризикуєте втратити її підтримки з боку виробника.

Процеси, які є другорядними для однієї компанії, можуть мати стратегічне значення в інших. Наприклад, мені доводилося консультувати одну фінансову компанію, в якій процес найму нових співробітників вважався одним з ключових стратегічних переваг над конкурентами. Вони намагалися наймати тільки кращих з кращих, витрачаючи багато часу і ресурсів на їх пошук. Одного разу вони запитали моєї поради щодо покупки готової системи управління кадрами, і я постарався їх відрадити. Навіщо втрачати свої переваги перед конкурентами? Вони послухалися моєї поради і створили свою власну систему. Це зайняло чимало часу, але в підсумку вони отримали платформу, яка полегшувала завдання, що коштували чимало зусиль їх конкурентам. Для багатьох організацій наймання співробітників - це не більше ніж один з аспектів господарської діяльності, але для тієї компанії він мав стратегічне значення.

Типізація в архітектурі

В процесі створінь SOAP-систем часто постає питання типізації та управління версіями розподілених компонентів. Він має більше технічне, ніж комерційний характер, проте часто є причиною грубих помилок в проектах такого роду. Це відбувається з двох причин: по-перше, легко піти на поводу у виробників програмного забезпечення, а по-друге, проблеми проявляються далеко не відразу. Більш того, самі неприємні проблеми - це саме ті, про які ви не знали на ранніх стадіях проекту.

Суперечка щодо того, чи можна створювати системи корпоративного рівня на мовах з динамічною типізацією, себе практично вичерпав, а нові аргументи тільки додають емоцій. Проте, ці дебати говорять про важливість типізації кінцевих точок в розподілених системах. Під кінцевими точками (endpoints) в даному випадку розуміється спосіб взаємодії між двома самостійними системами. В даний час існують два конкуруючих підходу до типізації: SOAP, який, як правило, вимагає суворої типізації з використанням таких стандартів, як мова опису Web-сервісів (Web Services Description Language - WSDL) та технологія REST (Representational State Transfer), що віддає перевагу більш вільну типізацію на основі документів (див. розділ ресурси ). Обговорення переваг і недоліків обох технологій виходить за рамки даної статті. Ми торкнемося лише переваги вільної типізації на рівні кінцевих точок, якій ви можете досягти, використовуючи обидва підходи.

Вільна тіпізація важліва для кінцевіх точок, оскількі смороду є частина публічного API для взаємодії Незалежності розвіваються систем. Внаслідок цього слід уникати сильної зв'язності сигнатур (типів і імен параметрів) між системами, оскільки це утруднить їх подальший розвиток, підвищить ризик помилок при взаємодії і ускладнить випуск нових версій однієї системи незалежно від іншої.

Розглянемо приклад. При традиційному, заснованому на SOAP поході до інтеграції додатків використовуються протоколи начебто віддаленого виклику процедур (RPC), а також WSDL для опису деталей обміну даними. Схема показана на малюнку 5.

Малюнок 5. Взаємодія між додатками в стилі RPC

При інтеграції в стилі RPC WSDL використовується для опису методів таким чином, щоб їх можна було викликати в SOAP. Іншими словами, кожен клас є тип в WSDL, також включає типи всіх параметрів методів. Цей підхід сильно пов'язує обидві взаємодіючі системи, оскільки їм доводиться покладатися на єдине опис відправлених і отриманих даних в WSDL. Подібне суворе опис є коренем проблеми. Що робити, якщо необхідно модифікувати один з додатків, наприклад, додати параметри виклику або змінити тип існуючого параметра, а ви не можете дозволити собі виконувати зміни синхронно в обох системах? Як управляти версіями кінцевих точок? Існує кілька шляхів вирішення цієї проблеми, але всі вони мають на увазі серйозні компроміси. Наприклад, ви можете створити ще одну кінцеву точку з новим описом WSDL. Якщо початкова точка доступу називалася addOrder, то другу можна назвати addOrder2. Напевно ви можете уявити собі, куди веде цей шлях. Дуже скоро у вас буде десяток злегка розрізняються точок і чимало дублюючого коду, оскільки складно передбачити те, як буде використовуватися точка доступу після її публікації. Крім того, ви можете спробувати використовувати кошти дозволу імен кінцевих точок, наприклад UDDI (Universal Description, Discovery, and Integration), який фактично являє собою хеш-таблицю, але цей підхід також страждає через погану масштабованості. Корінь проблеми полягає в сильній пов'язаності кінцевих точок, яка перешкоджає природному розвитку систем.

Альтернативний підхід до інтеграції кінцевих точок заснований на ідеї вільної типізації (рисунок 6).

Малюнок 6. Вільна типізація кінцевих точок

Передача інформації в кінцеву точку всередині документів дозволяє зберігати її опис незмінною при будь-яких змінах в обох взаємодіючих системах. Іншими словами, ви можете залишити собі свободу для маневру замість того, щоб строго описувати очікувану структуру даних в WSDL. Тепер кінцева точка приймає на вхід документ, що інкапсулює типи всіх переданих даних.

В умовах існування різних версій кінцевих точок необхідно в першу чергу розпакувати документ, визначити структуру переданих даних і узгодити її з очікуваною структурою. Особисто я, як правило, застосовую такі прийоми проектування, як "Фабрика" і "Стратегія" (див. Розділ ресурси ), Щоб визначити, чи відповідають отримані дані очікуваним (малюнок 7).

Малюнок 7. Аналіз вмісту всередині точки доступу для визначення його типів даних

Спочатку точка доступу повинна проаналізувати маніфест документа і визначити його вміст. Потім вона використовує об'єкт-фабрику для інстанціірованія відповідної стратегії вибірки інформації з документа. Після того як інформація була перевірена (наприклад, за допомогою WSDL), десеріалізованние об'єкти передаються в класи, що реалізують бізнес-логіку.

Цей підхід має ряд переваг. По-перше, на відміну від RPC цей механізм не виконує дві незв'язані між собою функції - надання публічного API для інтеграції і перевірку типів даних. Поєднання цих функцій в RPC призводить до заплутування коду, утруднення його подальшого розвитку і підтримки. По-друге, тепер кілька додатків можуть використовувати різні версії однієї кінцевої точки. Ви можете підтримувати будь-яку версію, для якої є відповідна стратегія (в тому числі старі версії, які складно оновити). Це дозволяє проводити зміни в міру необхідності, не турбуючись про те, що доведеться форсувати відповідні зміни в інших компонентах розподіленої системи. В даному випадку вони можуть переходити на нові версії документів за власним графіком.

На даний момент поки не існує інфраструктури, що дозволяє тривіальним чином реалізувати подібний принцип, але ви можете добитися цих переваг порівняно невеликими зусиллями. Зокрема, даний підхід можна реалізувати за допомогою SOAP або REST (в REST це зробити простіше завдяки його орієнтованості на документи). Створивши середу з вільною типизацией, ви дозволите всім групам розробників працювати в комфортному режимі, а загальної корпоративної системи - розвиватися з найменшими перешкодами. В основі еволюційної архітектури лежить саме ця ідея: закласти такий фундамент, який дозволяє вносити зміни в систему з максимальною швидкістю, найменшими витратами і не приносячи в жертву її можливості.

Висновок

Проектування архітектури - це велика і складна тема в області створення програмного забезпечення. У цій статті я постарався торкнутися безліч різних аспектів - від корпоративної політики до деталей управління версіями кінцевих точок в SOA. У наступних статтях ці ідеї будуть описані більш детально в контексті загального проектування архітектури, а також на прикладах деяких нових підходів до створення еволюціонують систем SOA, що не вимагають серйозних витрат на покупку ПО.

Ресурси для скачування

Схожі тими

• Оригінал статті: Evolutionary architecture and emergent design: Evolutionary architecture (Ніл Форд, developerWorks, січень 2010 р.) (EN)
• Прочитайте останню книгу Нілу Форда під назвою The Productive Programmer (O'Reilly Media, 2008 року), в якій більш детально розглядаються питання, порушені в цій статті. (EN)
• Зверніть увагу на класичну книгу Банди Чотирьох під назвою Прийоми об'єктно-орієнтованого проектування. патерни проектування (Еріх Гамма і ін., Erich Gamma et al., Addison-Wesley, 1994 г.), присвячену підходам до проектування додатків. (EN)
• Ознайомтеся з Apache Struts - популярної інфраструктурою з відкритим кодом для створення Web-додатків на Java. (EN)
• У книзі Людський фактор: успішні проекти і команди (Том Де Марко і Тімоті Лістер, Tom DeMarco and Timothy Lister, Dorset House Publishing, 1999 г.) наводиться ряд корисних порад щодо розв'язання соціальних проблем в процесі створення програмного забезпечення. (EN)
• Прочитайте обговорення технологій SOAP і REST в контексті створення SOA-додатків в статті Ресурс-орієнтовані і процес-орієнтовані Web-сервіси (Джеймс Снелл, James Snell, developerWorks, жовтень 2004 р.) (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів