3. Проблемы длительной разработки
• Число сущностей растет
• Число связей растет на порядок быстрее
• На каком-то этапе наступает коллапс разработки
4. Логическая компонента
• Компонента – автономная логическая единица кода
• Компонента предоставляет наружу контракт (см. далее)
• Компоненты взаимодействуют друг с другом
• Компонента – понятие рекуррентное (или фрактальное?..)
5. Связность (cohesion) и сцепление (coupling)
• Связность – мера силы взаимосвязанности элементов
внутри компоненты; способ и степень связанности между
задачами, выполняемыми компонентой
• Сцепление – мера, способ и степень взаимозависимости между
различными компонентами
7. Модульность
• Принцип модульности – код разделяется на отдельные
функционально законченные модули
• Контракт - формальное соглашение о способе использовании
модуля
• API (Application Programming Interface) – интерфейс
взаимодействия с модулем
• SPI (Service Provider Interface) – точки расширения модуля
• Часто интерфейс и реализацию разносят в раздельные модули
10. Этап проектирования системы
• Исходные данные – требования от заказчика
• Из требований следуют внешние свойства системы
• Задача проектирования – придумать внутреннее устройство
системы, обеспечивающее заданные внешние свойства
• Алгоритмы решения задач и требуемые структуры данных
• Архитектура системы – логические компоненты и связи между ними
• Механизмы хранения и передачи состояния
11. Многослойная (layered) архитектура
Система разбивается на несколько слоёв:
• Слой представления (View Layer)
• Управляющий слой (Controller Layer)
• Сервисный слой (Service Layer)
• Слой модели предметной области (Domain Model Layer)
• Слой источников данных (Data Sources Layer)
12. Слой источников данных
• Делает запросы к базам данных или другим внешним сервисам
• Например, к базе данных с банковскими счетами
• Формирует запросы и разбирает ответы
• Предоставляет интерфейс (API)
• CRUD операции (Create, Read, Update, Delete) над таблицами
• Часто используемые запросы
• Конструктор запросов
• Абстрагирует верхние слои от реалий конкретной базы данных
13. Слой модели предметной области
• Содержит в себе логику предметной области
• Например, управляет объектами «счёт в банке»
• Отвечает за целостность представления данных
• Например, что нельзя снять со счета больше денег, чем там есть
• Предоставляет интерфейс (API)
• CRUD операции над объектами предметной области
• Типовые модификации (перевод денег между счетами)
• Метаинформация (число открытых счётов)
• Абстрагирует верхние слои от управления состоянием
предметной области
14. Сервисный слой
• Отвечает за взаимодействие между компонентами предметной
области
• Например, за взаимодействие счетов и покупок
• Управляет выполнением запросов от пользователя
• Предоставляет бизнес-ориентированный интерфейс (API)
• Сделать покупку
• Перевести со счета на счет
• Ввести деньги на счет
• Создать нового пользователя
15. Управляющий слой (контроллер)
• Отвечает за приемку управляющих команд от пользователя или
других сервисов
• Аргументы командной строки
• REST или SOAP интерфейс
• TCP или Unix socket
• Перенаправляет управляющие команды в сервисный слой
• При необходимости использует данные от слоя модели
• Сообщает пользователю результат выполнения команды
16. Слой представления
• Взаимодействует с человеком
• Предоставляет человекочитаемый интерфейс
• Web-приложение с HTML-выдачей
• Графическое оконное приложение (WinAPI, QT, ...)
• Утилита командной строки
• Перенаправляет все запросы к контроллеру
• Принимает ответы от контроллера
17. Пример многослойной архитектуры
• Представление – Web-сервис управления банковским счетом
• http://coolbank.ru/
• Контроллер – HTTP-контроллер
• http://coolbank.ru/register – открыть новый счет
• http://coolbank.ru/account - информация о счете
• http://coolbank.ru/transfer – сделать перевод
• Сервисный слой – класс AccountService
• accountService.newAccount(String name);
• accountService.getAccount(String name);
• accountService.transfer(String source, String dest, double amount);
• Слой модели – класс BalanceManager
• balanceService.getBalance(int accountId);
• balanceService.add(int accountId, double amount);
• Слой источников данных – класс BalanceDAO
• balanceDao.getBalance(int accountId);
• balanceDao.updateBalance(int accountId, double newAmount);
20. Разновидности шаблонов проектирования
• Порождающие – создание новых объектов
• Структурные – организация интерфейсов между объектами
• Поведенческие – взаимодействие между объектами и деление
ответственности
• Архитектурные, фундаментальные, конкурентные,
корпоративные, ...
Сложность рефакторинга – тяжело осмыслить
Сложность изменения API
Время вхождения (нового разработчика)
Коэффициент автобуса
Рекуррентное – функция – класс – модуль – приложение – система – бизнес-юнит
Модульность улучшает переиспользование, упрощает проектирование, упрощает дистрибуцию
Contract-first Development - парадигма разработки “от контракта”
Переизбыток зависимостей в системе вызывает непредсказуемые проблемы
Разделение реализации и интерфейса сильно сокращает объем знаний и зависимостей, необходимый для использования модуля
Архитектура – совокупность важнейших решений о структуре системы; всё, что тяжело изменить
Архитектура может быть у каждой логической компоненты