Курс лекций для СТАНКИН. 2011 год.

1. Архитектура ПО
Разработка бизнес приложений
Лекция 9

2. Что такое архитектура
• Четкого определения нет
• Все что отвечает на вопрос «а как именно
это сделать»?
– Классы
– Компоненты (модули, сервисы, слои)
– Процессы и приложения
– Физические сервера
• Совокупность тяжело изменяемых решений
принимаемых в процессе проектирования

3. Зачем нужно думать о ней заранее?
• Некоторые вещи очень сложно сделать в
процессе
• Нужно постоянно бороться со сложностью
(энтропией)
• В принципе, идеальная команда все
знающих программистов может «просто
писать код» и, скорее всего, все у них будет
хорошо

4. Две архитектуры
• Логическая
– Как организован код внутри – слои, модули
– Выбор готовых компонентов и инструментов
• Физическая
– Набор, ответственность и взаимосвязь
процессов ОС
– Вопросы размещения процессов на физ.
серверах, масштабирования

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

6. Слои (layers)
• Способ представления программы в виде
слабо зависимых кусков
– Прежде всего, логических кусков
– Но, бывает, что слои и физически разделены
• Каждый слой оперирует собственным
набором терминов и понятий
– Следовательно, проще в понимании чем
система целиком

7. Преимущества слоев
• Упрощение изучения системы
• Можно выбрать альтернативную реализацию
того или иного слоя
– (в теории)
• Каждый слой является удачным кандидатом
на стандартизацию / автоматизацию
• Созданный слой может служить основой для
нескольких различных слоёв более высокого
уровня.

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

9. Три основных слоя
• DAL (Data access layer)
– Как сохранять и получать данные (persistent)
– Постепенно отмирает, заменяется ORM+БД
• BL(L) (Business logic layer)
• Как делать работу, выполнять бизнес операции
• UI (User Interface layer, представление)
– От HTML до консоли или API
– Как выводить результаты

10. Вариант DAL: прямые запросы
• Открываем соединение
• Отправляем запрос
• Получаем строки БД
• Закрываем соединение
• Доступно на любом языке, масса
стандартных библиотек
– JDBC, ADO.NET, ODBC…

11. Достоинства
• Полный контроль над кодом доступа к БД
• Возможность использовать нестандартный
SQL, сложным образом оптимизировать
запросы
• Подход не требует никаких нестандартных
библиотек, прост в установке и настройке
• Простота освоения. Нужно просто знать SQL
• Относительно высокая скорость работы
конечного приложения. Но только при
хорошем SQL коде.

12. Недостатки
• Огромное дублирование кода, весь код -
однотипный
• Высокая вероятность ошибок, т.к. SQL не
проверяется автоматически
• Низкая скорость разработки, так как приходиться
аккуратно писать большое количество однотипного,
не проверяемого кода
• Нужно хорошее знание SQL
• Сложность внесения изменений, из-за большого
количества дублируемого интерпретируемого кода
• Зависимость от конкретного диалекта СУБД

13. В результате – DAL и ORM
• DAL как попытка исключить дублирование
кода
• Естественное желание автоматически
загружать строки из БД в виде объектов, а
не слабо типизированных таблиц.
• ORM (Object-relational mapping)
– Библиотека осуществляющее автоматическое
преобразование (mapping) реляционных
данных в объекты и обратно

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

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

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

17. Идентификация
• В БД строка всегда одна
– Характеризуется PK
• В памяти приложения можно создать
несколько объектов отображающих одну и
ту же строку
– Характеризуются адресами в памяти
• ORM должен предлагать консистентные
правила идентификации отображенных
объектов

18. Моделирование связей
• С т.ч. объектной модели мы имеем дело с
простым графом объектов
– переходы по ссылкам между объектами –
тривиальны
• С т.ч. БД мы имеем дорогостоящие запросы по
FK, сложные JOIN и, потенциально,
бесконечное количество данных
• ORM должен предлагать подходы к решению
этой проблемы
– Lazy loading (+/-)
– Eager loading (решение n+1)

19. Слой бизнес логики (модель)
• Объекты предметной области
• В контроллерах (UI)
• Набор отдельных методов (Transaction
Script)
• Промежуточный вариант UnitOfWork
(бизнес транзакция) + ORM + команды

20. Слой UI. MVC
• Вариации -> MVVM(C), MVP
• Зависит от UI фреймворка, но хороший фреймворк
всегда отделяет view от управления UI и бизнес логики
– Тестируемость
– Императивный код во View (asp/php макароны)

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

22. Шаблон Inversion of Control
(Dependency Injection)
• Состав
– Контейнер: «интерфейс» – «реализация»
– Инжектор (автоматический или не очень)
• Преимущества
– Снижение каплинга, повышение гибкости, возможность
реализации AoP (иногда)
• Недостатки
– Код становится менее прозрачным при чтении
– Доп. сложность и конфигурация
– Поощрение мешанины зависимостей
• Фактически, это замена качественного проектирования
слоев / модулей и логической архитектуры как таковой
– Редко когда действительно нужно

23. Общие рекомендации.
Не усложняйте.
• ORM + MVC на основе готовых
фреймворков
• Без выделенного слоя бизнес логики
• Без DI / IoC
• Без явного выделения слоев
• Без явного деления на модули
– если не нужны плагины (тогда нужно делать их)

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

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

26. Преимущества физического разделения
• Общий прозрачный доступ к географически
распределенным ресурсам
• Открытость – предоставление доступа к
частям системы через программные
интерфейсы (интеграция)
• Масштабируемость
• Упрощение большой системы (разделение
на куски)
• Отказоустойчивость

27. Недостатки физического разделения
• Возможно сокращение отказоустойчивости
– если нет горячего дублирования
• Снижение производительности за счет
сериализации / десериализации (маршаллинга) и
задержек передачи данных
– Если неправильно распараллеливается нагрузка
• Дополнительная сложность
– требования сериализации объектов
– DTO, фасады, доп. слои
– Отсутствие состояния или параллельный доступ к нему
– Сложная конфигурация развертывания

28. Способы связи
• TCP/IP (сокеты)
– Быстро и сложно, не масштабируется
• Системы распределённых объектов
– Не очень хорошо работают, слишком прозрачны,
закрытые и требующие изучения реализации
• Вызов удалённых процедур
– Стандартно, прозрачно и несложно, но не быстро и
дает сложную связь по интерфейсам
• Системы передачи сообщений.
– Строго асинхронно, весьма сложно, нужны отдельные
приложения со своей инфраструктурой и сложностями

29. Клиент-сервер (2-tier?)
• Веб приложение – подходит или нет?
• Чаще всего под этим понимают классический
толстый клиент к БД (1С)
• Не масштабируется по географии и кол-ву
пользователей
• Сложности в развертывании
администрировании и защите (БД открыта)

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

31. Peer to peer (p2p)
• Специфические области применения
– Torrents
– Skype
– Научные вычисления
• Проблемы обнаружения (discovery)
• Сложность разработки и отладки

32. Состояние сеанса (сессия)
• На стороне клиента
– Cookies
– Hidden fields
– Толстый клиент (rich client)
• На стороне сервера
– В памяти сервера
– В распределенном кэше
– В базе данных

33. SOA
• Сервис = все слои, законченый функционал
• Распределяем не слои, а сервисы
• Психология – неявные сервисы в коде vs
явные веб сервисы
• Нарезаем вертикально, а не горизонтально
• Например: протоколы OSI (часто приводят
как слои, но я считаю что это сервисы)
– Ethernet - TCP/IP - HTTP

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

35. Проблемы интеграции
• Минимизация связности
– Нельзя усложнять развитие каждой системы, т.к. релиз циклы и
скорость развития обычно существенно различны
• Сложность интеграции
– Чаще всего требуется сделать очень быстро, без существенных
изменений в одной из систем или без изменений вовсе.
• Договоренность о формате данных
• Синхронная или асинхронная (допустимое время запаздывания
данных, интеграция данных или функциональности)
– Конфликты данных при асинхронном обмене
– Обработка ошибок когда одно из приложений недоступно
– Проблемы распределенных транзакций при синхронном обмене

36. Способы интеграции
• Обмен файлами
• Разделяемая БД
• Remote Procedure Call (XML-RPC, Web services,
REST), т.е. вызов удаленных функций
– Реальный RPC (как функции, синхронный)
– Импорт / Экспорт (как замена обмена файлами,
асинхронно)
• Передача сообщений (messaging)
– Общая система обмена сообщениями, которая
позволяет обмениваться данными и командами в
виде сообщений.

37. Распределенные транзакции
• Распределенные транзакции
– Очень сложно
– Медленно
• По возможности – заменяем
идемпотентной операциями
– Вторая и последующая операция ничего не
меняют по отношению к 1й
– Легко реализуется через уникальные ID / Guid

38. Рекомендации по интеграции
• RESTful web сервисы на основе XML (и/или
JSON)
– WS* (SOAP) – отказать
• Односторонняя интеграция без конфликтов
данных
– Простые очереди или периодические запросы
• Никаких распределенных транзакций
– Идемпотентность – transactionid + очереди в БД
• При синхронной интеграции воспринимайте
систему как единое целое
– Т.е. просто падаем, если что-то не работает

39. Рекомендации по распределённости
• Выберите веб приложение: веб сервер(а) + БД,
потом успеете распределить
– Минимум состояния сеанса (лучше без)
• Распределяйте вертикально, не горизонтально
– SOA
• Избегайте географического распределения и
любой двухсторонней синхронизации данных
• Идеал – прототипы и нагрузочное
тестирование, очень трудно угадать влияние
распределённости на производительность

40. Совсем общие рекомендации
• Смысл архитектуры – борьба со сложностью, а не ее
внесение
– BDUF - антипаттерн
– Заранее нужно принимать только решения
направленные на борьбу с «очевидными» рисками
– Проектировать только то, что потом будет сложно
(дорого) изменить
• Используйте готовое
– NiH синдром
– Всегда приходится чем-то жертвовать (где граница?)
• В остальном - решать конкретные проблемы

41. Читаем
• Шаблоны корпоративных приложений
• Предметно-ориентированное
проектирование (DDD)
• Применение DDD и шаблонов
проектирования. Проблемно-
ориентированное проектирование
приложений с примерами на C# и .NET

42. Использованные материалы
• Никита Филлипов (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 (Мартин Фаулер)

43. Объявления
• 8го экзамен

44. Темы для докладов
• AOP
• Kanban / Lean
• SCRUM: Team / ScrumMaster – подробнее
про процесс (DS, Retro, SprintPlan, Demo…)
• NoSql БД
• Реализация ООП в Javascript (прототипы)

45. Лабы
• Обработка открытых данных
– 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/
• Индивидуальное задание (для тех, у кого уже есть
что показать)
• Нужно:
– Или наличие БД
– Или наличие веб интерфейса