разработка бизнес приложений (9)

Архитектура ПО

Разработка бизнес приложений Лекция 9

Что такое архитектура

• Четкого определения нет• Все что отвечает на вопрос «а как именно

это сделать»?– Классы– Компоненты (модули, сервисы, слои)– Процессы и приложения– Физические сервера

• Совокупность тяжело изменяемых решений принимаемых в процессе проектирования

Зачем нужно думать о ней заранее?

• Некоторые вещи очень сложно сделать в процессе

• Нужно постоянно бороться со сложностью (энтропией)

• В принципе, идеальная команда все знающих программистов может «просто писать код» и, скорее всего, все у них будет хорошо

Две архитектуры

• Логическая– Как организован код внутри – слои, модули– Выбор готовых компонентов и инструментов

• Физическая– Набор, ответственность и взаимосвязь

процессов ОС– Вопросы размещения процессов на физ.

серверах, масштабирования

ЛОГИЧЕСКАЯ АРХИТЕКТУРА

Слои (layers)

• Способ представления программы в виде слабо зависимых кусков– Прежде всего, логических кусков– Но, бывает, что слои и физически разделены

• Каждый слой оперирует собственным набором терминов и понятий– Следовательно, проще в понимании чем

система целиком

Преимущества слоев

• Упрощение изучения системы• Можно выбрать альтернативную реализацию

того или иного слоя– (в теории)

• Каждый слой является удачным кандидатом на стандартизацию / автоматизацию

• Созданный слой может служить основой для нескольких различных слоёв более высокого уровня.

Недостатки слоев

• Каскадные изменения практически неизбежны

• Очень трудно четко определить, донести до всех и проконтролировать (!) границы ответственности слоя– Если слои физически не разделены

Три основных слоя

• DAL (Data access layer)– Как сохранять и получать данные (persistent)– Постепенно отмирает, заменяется ORM+БД

• BL(L) (Business logic layer)• Как делать работу, выполнять бизнес операции

• UI (User Interface layer, представление)– От HTML до консоли или API– Как выводить результаты

Вариант DAL: прямые запросы

• Открываем соединение• Отправляем запрос• Получаем строки БД• Закрываем соединение• Доступно на любом языке, масса

стандартных библиотек– JDBC, ADO.NET, ODBC…

Достоинства

• Полный контроль над кодом доступа к БД• Возможность использовать нестандартный SQL,

сложным образом оптимизировать запросы• Подход не требует никаких нестандартных

библиотек, прост в установке и настройке• Простота освоения. Нужно просто знать SQL• Относительно высокая скорость работы

конечного приложения. Но только при хорошем SQL коде.

Недостатки

• Огромное дублирование кода, весь код - однотипный• Высокая вероятность ошибок, т.к. SQL не проверяется

автоматически• Низкая скорость разработки, так как приходиться

аккуратно писать большое количество однотипного, не проверяемого кода

• Нужно хорошее знание SQL• Сложность внесения изменений, из-за большого

количества дублируемого интерпретируемого кода• Зависимость от конкретного диалекта СУБД

В результате – DAL и ORM

• DAL как попытка исключить дублирование кода

• Естественное желание автоматически загружать строки из БД в виде объектов, а не слабо типизированных таблиц.

• ORM (Object-relational mapping)– Библиотека осуществляющее автоматическое

преобразование (mapping) реляционных данных в объекты и обратно

Сложности реализации ORM

• Гранулярность (Granularity)• Подтипы (Subtypes)• Идентификация (Identity)• Навигация по связям (Graph Navigation)

Гранулярность

• Удобные (оптимальные) формы хранения объектных и реляционных данных далеко не всегда совпадают

Наследование

1. TPT (нужны запросы к базовому классу)2. TPCT (к отдельным классам)3. TPH (ко всем разом)

1

2

3

Идентификация

• В БД строка всегда одна– Характеризуется PK

• В памяти приложения можно создать несколько объектов отображающих одну и ту же строку– Характеризуются адресами в памяти

• ORM должен предлагать консистентные правила идентификации отображенных объектов

Моделирование связей

• С т.ч. объектной модели мы имеем дело с простым графом объектов – переходы по ссылкам между объектами – тривиальны

• С т.ч. БД мы имеем дорогостоящие запросы по FK, сложные JOIN и, потенциально, бесконечное количество данных

• ORM должен предлагать подходы к решению этой проблемы – Lazy loading (+/-)– Eager loading (решение n+1)

Слой бизнес логики (модель)

• Объекты предметной области• В контроллерах (UI)• Набор отдельных методов (Transaction

Script)• Промежуточный вариант UnitOfWork

(бизнес транзакция) + ORM + команды

Слой UI. MVC

• Вариации -> MVVM(C), MVP• Зависит от UI фреймворка, но хороший фреймворк

всегда отделяет view от управления UI и бизнес логики– Тестируемость– Императивный код во View (asp/php макароны)

Модули

• Попытка разделить физическое приложение вертикально, обособив некие относительно независимые части, каждую со своим стеком слоев UI / BL / DAL.

• Сложно в реализации и поддержке, мало плюсов, т.к. разделение сугубо логическое.

• Имеет смысл в виде динамических плагинов

Шаблон Inversion of Control (Dependency Injection)

• Состав– Контейнер: «интерфейс» – «реализация»– Инжектор (автоматический или не очень)

• Преимущества– Снижение каплинга, повышение гибкости, возможность реализации

AoP (иногда)• Недостатки

– Код становится менее прозрачным при чтении– Доп. сложность и конфигурация – Поощрение мешанины зависимостей

• Фактически, это замена качественного проектирования слоев / модулей и логической архитектуры как таковой– Редко когда действительно нужно

Общие рекомендации. Не усложняйте.

• ORM + MVC на основе готовых фреймворков

• Без выделенного слоя бизнес логики• Без DI / IoC • Без явного выделения слоев• Без явного деления на модули– если не нужны плагины (тогда нужно делать их)

ФИЗИЧЕСКАЯ АРХИТЕКТУРА

Распределенные системы

• Распределённая система состоит из различных процессов ОС, чаще всего распределенных по серверам различной степени удаленности и связности– Клиент-сервер БД – Веб приложение с логикой на клиенте– Географически распределенные системы

Преимущества физического разделения

• Общий прозрачный доступ к географически распределенным ресурсам

• Открытость – предоставление доступа к частям системы через программные интерфейсы (интеграция)

• Масштабируемость• Упрощение большой системы (разделение

на куски)• Отказоустойчивость

Недостатки физического разделения

• Возможно сокращение отказоустойчивости – если нет горячего дублирования

• Снижение производительности за счет сериализации / десериализации (маршаллинга) и задержек передачи данных – Если неправильно распараллеливается нагрузка

• Дополнительная сложность – требования сериализации объектов– DTO, фасады, доп. слои– Отсутствие состояния или параллельный доступ к нему– Сложная конфигурация развертывания

Способы связи

• TCP/IP (сокеты)– Быстро и сложно, не масштабируется

• Системы распределённых объектов– Не очень хорошо работают, слишком прозрачны,

закрытые и требующие изучения реализации• Вызов удалённых процедур

– Стандартно, прозрачно и несложно, но не быстро и дает сложную связь по интерфейсам

• Системы передачи сообщений.– Строго асинхронно, весьма сложно, нужны отдельные

приложения со своей инфраструктурой и сложностями

Клиент-сервер (2-tier?)

• Веб приложение – подходит или нет?• Чаще всего под этим понимают классический

толстый клиент к БД (1С)• Не масштабируется по географии и кол-ву

пользователей• Сложности в развертывании администрировании

и защите (БД открыта)

N-Tier (многозвенная)

• Веб приложение – подходит или нет?• Хуже скорость реакции (?)• Беднее интерфейс (?)• Одностороннее взаимодействие (?)

Peer to peer (p2p)

• Специфические области применения– Torrents– Skype– Научные вычисления

• Проблемы обнаружения (discovery)• Сложность разработки и отладки

Состояние сеанса (сессия)

• На стороне клиента–Cookies–Hidden fields– Толстый клиент (rich client)

• На стороне сервера–В памяти сервера–В распределенном кэше–В базе данных

SOA

• Сервис = все слои, законченый функционал• Распределяем не слои, а сервисы• Психология – неявные сервисы в коде vs

явные веб сервисы• Нарезаем вертикально, а не горизонтально• Например: протоколы OSI (часто приводят

как слои, но я считаю что это сервисы)– Ethernet - TCP/IP - HTTP

Что такое интеграция

• Частный случай распределённости, когда одна из частей системы написана и/или контролируется не вами

• Часто возникает не от «хорошей» (с т.ч. IT) жизни (но бывает и намеренным решением)– Слияние предприятий– Бурное развитие с последующей консолидацией IT– Системы допоставок– Невозможность написать одну систему на все

предприятие

Проблемы интеграции• Минимизация связности

– Нельзя усложнять развитие каждой системы, т.к. релиз циклы и скорость развития обычно существенно различны

• Сложность интеграции– Чаще всего требуется сделать очень быстро, без существенных

изменений в одной из систем или без изменений вовсе.• Договоренность о формате данных • Синхронная или асинхронная (допустимое время

запаздывания данных, интеграция данных или функциональности)– Конфликты данных при асинхронном обмене – Обработка ошибок когда одно из приложений недоступно– Проблемы распределенных транзакций при синхронном обмене

Способы интеграции

• Обмен файлами• Разделяемая БД• Remote Procedure Call (XML-RPC, Web services,

REST), т.е. вызов удаленных функций– Реальный RPC (как функции, синхронный)– Импорт / Экспорт (как замена обмена файлами,

асинхронно)• Передача сообщений (messaging) – Общая система обмена сообщениями, которая позволяет

обмениваться данными и командами в виде сообщений.

Распределенные транзакции

• Распределенные транзакции– Очень сложно– Медленно

• По возможности – заменяем идемпотентной операциями– Вторая и последующая операция ничего не

меняют по отношению к 1й– Легко реализуется через уникальные ID / Guid

Рекомендации по интеграции

• RESTful web сервисы на основе XML (и/или JSON)– WS* (SOAP) – отказать

• Односторонняя интеграция без конфликтов данных– Простые очереди или периодические запросы

• Никаких распределенных транзакций– Идемпотентность – transactionid + очереди в БД

• При синхронной интеграции воспринимайте систему как единое целое– Т.е. просто падаем, если что-то не работает

Рекомендации по распределённости

• Выберите веб приложение: веб сервер(а) + БД, потом успеете распределить– Минимум состояния сеанса (лучше без)

• Распределяйте вертикально, не горизонтально– SOA

• Избегайте географического распределения и любой двухсторонней синхронизации данных

• Идеал – прототипы и нагрузочное тестирование, очень трудно угадать влияние распределённости на производительность

Совсем общие рекомендации

• Смысл архитектуры – борьба со сложностью, а не ее внесение– BDUF - антипаттерн– Заранее нужно принимать только решения направленные

на борьбу с «очевидными» рисками– Проектировать только то, что потом будет сложно (дорого)

изменить• Используйте готовое

– NiH синдром– Всегда приходится чем-то жертвовать (где граница?)

• В остальном - решать конкретные проблемы

Читаем

• Шаблоны корпоративных приложений• Предметно-ориентированное проектирова

ние (DDD)

• Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET

Использованные материалы

• Никита Филлипов (www.scrumtrek.ru), Сергей Дмитриев (www.agilecoach.ru). Курс SCPO Msk (31.08.11)

• Бочков Илья (Архитектура корпоративных приложений, МИФИ)

• MIT: открытые лекции по CS– http://ocw.mit.edu/courses/#

electrical-engineering-and-computer-science• http://www.refactoring.com (Мартин Фаулер)

Объявления

• 8го экзамен

Темы для докладов

• AOP• Kanban / Lean • SCRUM: Team / ScrumMaster – подробнее

про процесс (DS, Retro, SprintPlan, Demo…)• NoSql БД• Реализация ООП в Javascript (прототипы)

Лабы

• Обработка открытых данных– http://minenergo.gov.ru/activity/statistic/,http

://www.fms.gov.ru/about/ofstat/, http://www.federalspace.ru/main.php?id=10, http://ivan.begtin.name/2011/10/02/gosuslugijson/

• Индивидуальное задание (для тех, у кого уже есть что показать)

• Нужно:– Или наличие БД– Или наличие веб интерфейса