Маленька замальовка на тему того, як розробити високорівневу архітектуру програми.
Припустимо, що з майбутньою функціональністю Ви визначилися. Тоді Ви точно знаєте, хто або що буде поставляти дані, хто/що буде їх споживати і які перетворення даних повинна виконувати сама система.
Візьміть аркуш паперу і олівець. Якщо не сильно впевнені в своїх силах, то ще й гумку, щоб правити схему. Більш просунуті читачі можуть звернутися до професійних інструментів для проектування архітектури в електронному вигляді.
Тепер з'ясуйте, хто буде звертатися до вашої системи, щоб передати або забрати дані, а до чого буде звертатися Ваша програма. Ті системи або користувачі, які звертаються до програми самі, намалюйте схематично на аркуші паперу вгорі. Ті, до яких буде звертатися програма (включаючи БД), - знизу.
Тепер намалюйте під кожним намальованим зверху суб'єктом прямокутник з назвою UI або API - це інтерфейси, до яких буде звертатися користувач або зовнішня управляюча система. Іноді UI теж може звертатися до API. Об'єднайте всі прямокутники з UI одним контуром і назвіть шаром перегляду. Об'єднайте всі прямокутники з API і назвіть шаром сервісів.
Для систем, намальованих знизу, вкажіть компоненти, які відповідатимуть за доступ до цих систем. Об'єднайте всі ці компоненти одним контуром і назвіть шаром доступу до даних.
Між шаром сервісів і шаром доступу до даних намалюйте великий контур і назвіть його шаром бізнес-логіки. У маленьких прямокутниках всередині цього контуру перерахуйте основні бізнес-завдання. Один компонент Вашої системи буде вирішувати одну бізнес-задачу.
Тепер праворуч намалюйте кілька довгих прямокутників знизу доверху і напишіть в них: журналування, конфігурація, моніторинг продуктивності, обробка винятків і щось інше, що є загальною інфраструктурою (або наскрізною функціональністю) для всіх шарів вашої програми.
Ви отримали логічну архітектуру програми. Розкидайте шари по серверах - отримайте фізичну архітектуру.
Тепер вам залишається детально опрацювати кожен маленький квадратик.
Маленький практичний приклад запрячу під кат.
Для прикладу я візьму абсолютно віртуальний проект системи контролю успішності для середньої школи. Візьму її з двох причин. По-перше, всі ми вчилися в школі. По-друге, у багатьох з нас діти зараз навчаються в тій же школі. Через це, сподіваюся, предметна область буде всім зрозуміла.
Отже, наша система буде призначена для ведення електронних щоденників учнів та електронних класних журналів. У довісок нехай система має деякий додатковий набір функцій, що дозволяє учням, батькам і викладачам обмінюватися повідомленнями, а керівництву школи - контролювати навчальний процес.
Отже, користувачами нашої системи будуть учні, їхні батьки, вчителі та керівництво школи. Крім того, користувачами будуть адміністратори системи, яким важливо отримувати інформацію про події в системі і виконувати деякі сервісні операції. Перераховувати варіанти використання не будемо, не про них мова.
Користувачі будуть взаємодіяти з нашою системою або за допомогою web-інтерфейсу, або за допомогою мобільного додатку. Обидва користувальницьких інтерфейсу призначені для шкіл, які не можуть собі дозволити розробку свого власного сайту. Інші зможуть звертатися до нашої системи через web-сервіси.
Сервісів буде чотири: електронний щоденник, електронний журнал, організація навчального процесу та адміністрування.
Під шаром сервісів буде шар бізнес-логіки, що складається з десятка компонентів, що вирішують бізнес-завдання користувачів.
Дані зберігатимуться у базі даних. Причому бази буде дві: бойова і архівна.
Система експортуватиме/імпортуватиме дані з файлів. Крім того, буде дві зовнішні системи, до яких наша система буде з'єднуватися віддалено: система довідкової інформації та інформаційна система Департаменту освіти.
Наскрізну функціональність складатимуть механізми журналування, моніторингу, управління конфігурацією, забезпечення безпеки.
У підсумку, отримуємо ось таку просту схему:
Тепер можна виділити фізичні вузли. Web-інтерфейс користувача і сервіси будуть розгорнуті в web-кластері. Шари бізнес-логіки та доступу до даних будуть реалізовані на сервері додатків. Бази даних розмістяться в окремому відмовостійкому кластері. Пізніше можна буде всі вузли зобразити у вигляді красивої схеми фізичної архітектури.
Сподіваюся, приклад зрозумілий.
Для того, щоб більш глибоко зануритися в тему, пропоную звернути увагу на «Керівництво Microsoft з проектування архітектури додатків». Керівництво написано у формі довідника, так що можна швидко знайти рекомендації щодо проектування кожного шару системи.