Архитектурные стили

1.

Архитектурные стили

2.

Архитектура

3.

При использовании DDD подхода мы
фокусируемся на смысловом ядре
предметной области
Архитектура должна поддерживать эту
возможность, защищая содержимое
смыслового ядра от посторонней логики

4.

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

5.

Я хочу иметь возможность
сосредоточиться на сложных
аспектах системы по отдельности,
поэтому когда мне становится
сложно это делать, я начинаю
разбивать классы и выделять новые
Дядюшка Боб

6.

Если мы выбрали DDD то само собой
разумеется одним из самых узких мест в
нашем проекте является сложность бизнес
логики
Соответственно, выносим бизнес логику в
отдельные компоненты

7.

Классическая многоуровневая
архитектура
Архитектуры ориентированные
на домен
Основа – слой работы с данными
Основа – бизнес логика

8.

1
2
Business Logic (BLL)
1
Data Access (DAL)
Infrastructure
Presentation
1. Нижние уровни не взаимодействуют с верхними
2. Проход через слой (не)допустим

9.

Невозможно предотвратить
распределение кода модели между
уровнями
Соответственно бизнес логика
привязывается к коду не относящемуся
к доменному слою

10.

Бизнес слой должен быть
Тестируемым
Бизнес правила могут быть протестированы напрямую
(не через UI, DB, веб-сервис и т.п.)
Независимым от используемого каркаса (Frameworks)
Каркас это инструмент, который не должен накладывать
ограничения на ко доменной модели
Независимым от UI
UI может быть заменен без изменения доменной модели
Независимым от способа хранения данных (Database)
Вы можете переключаться между реляционными и NoSQL
базами данных без изменения в коде бизнес логики
Независимым от внешних служб
Ваша бизнес логика вообще не должна знать о существовании
внешних сервисов

11.

The Clean Architecture
Uncle Bob
Hexagonal Architecture (a.k.a. Ports and Adapters)
Alistair Cockburn
Адаптировано Steve Freeman, Nat Pryce
Growing Object Oriented Software
Onion Architecture
Jeffrey Palermo
Screaming Architecture
blog of Uncle Bob
DCI
James Coplien, Trygve Reenskaug
BCE
Ivar Jacobson from
Object Oriented Software Engineering:
A Use-Case Driven Approach

12.

13.

Framework
Application
Domain
Core
Domain

14.

Под различные внешние ресурсы заводим
порты, которые могут быть использованы
(адаптированы) для использования другими
слоями
Примеры внешних ресурсов
файловая система,
сетевые хранилища
API третьих систем
база данных
пользовательский интерфейс

15.

1. С помощью тестов и заглушек
(in-memory database)
прорабатываем бизнес слой
2. Дописываем GUI продолжая
работать с заглушкой DB
3. Используя интеграционные
тесты (под CI) добавляем
реальную базу данных с
тестовыми данными
4. Передаем на приемку
Проверяем
работоспособность всех
компонент системы

16.

1. Приложение строится вокруг
независимой объектной модели
2. Внутренние слои закрыты
интерфейсами
Внешние слои реализуют интерфейс
3. Ассоциации направлены всегда к центру
4. Код ядра приложения может быть
скомпилирован и запущен отдельно от
инфраструктуры
Jeffrey Palermo
2008

17.

18.

Модуль таблицы (Table Module)
представляет собой объект, в единственном экземпляре,
обрабатывающий бизнес логику для всех записей в
таблице базы данных, либо представления
Сценарий транзакции (Transaction script)
организует взаимодействие с бизнес-логикой
посредствам процедур, принимающих запросы с уровня
представления
Модель предметной области (Domain Model)
непосредственно, объектная модель предметной
области, включающая в себя как поведение, так и данные
«Архитектура корпоративных программных приложений»
Patterns of Enterprise Application Architecture (P of EAA)
Мартин Фаулер

19.

Логика простая
Сценарий транзакции
Логика сложная
Модель предметной области
Логика средней сложности
Среда разработки позволяет
манипулировать множеством записей
Модуль таблицы

20.

На уровне приложения реализуются сервисы
приложения (Application Service) управляющие
логикой приложения
Логика приложения представляет собой реализацию
прецедента использования (Use Case)
Не должна сводиться к банальному CRUD
подвержена изменению в меньшей степени, чем бизнес
логика (изменяется при изменении контракта)
Сервис приложения является фасадом для доменного
слоя
Сервис приложения трансформирует бизнес модель в
модель представления

21.

Интерфейс доступа к домену
domain façade
Сценарий операции
operation script
Разделение моделей команд и запросов
CQRS
Модель чтения (Read Model)
Модель записи (Write Model)

22.

Содержит службы которые представляют
собою
Порты для подключения к внешним ресурсам
Адаптеры для подключения к слою логики
приложения

23.

Бизнес логика не должна размазываться по
слоям приложения
Smart UI
Бизнес логика описывается на слое представления
FSUC (Fat Stupid Ugly Controller)
Анти-паттерн характерный для MVC стиля, бизнес
логика формируется на контролерах
Логика не относящаяся к бизнес логике не
должна засорять доменную модель
Active Record
Логика взаимодействия с базой данных
формируется в доменной модели

24.

Интеллектуальный пользовательский интерфейс
Smart UI
1. Он позволяет получить видимый результат
исключительно быстро
2. Если проект очень мал (и не будет расти), т.е. сложность
никогда не станет проблемой, то стоимость более
изощренной архитектуры перевешивает ее преимущества
3. Имеется наиболее очевидная ассоциация между
элементами графического пользовательского интерфейса и
подпрограммами в коде

25.

Толстые тупые уродливые контроллеры
Fat Stupid Ugly Controllers
Pádraic Brady (Zend Framework)
FSUC получает данные из БД (используя
уровень абстракции базы данных, делая вид,
что это модель) или манипулирует, валидирует,
записывает, а также передает данные в
представление
Контроллер - Модель мутант

26.

Толстый (содержащий модель) контроллер
практически не поддается переносу и тестированию
(TDD)
мы не можем создать экземпляр класса
контроллера вне Фреймворка, контроллер жестко
привязан к определенному Фреймворку
Вид должен по возможности избегать контакта с
Контроллером и получать данные напрямую из
модели
Мне не нужно думать куда разместить бизнес
логику

27.

Активная запись (Active Record)
активная запись используется наиболее
очевидный подход, при котором логика
доступа к данным включается в объект
домена

28.

Слой представления (UI)
Стиль MVC (Model View Controller)
Может быть представлен различными паттернами
(MVC, MVP, MVVC и т.п.)
DCI
Слой взаимодействия с базой данных (DAL)
Неявное сохранение (Persistence Ignorant)
Доменные объекты недолжны быть связаны с
объектами DAL слоя (ни наследование, ни
дополнительные атрибуты не допускаются)
Паттерны O/R преобразования
в частности Unit of Work

29.

Вызов
Синхронный
▪ Прямой вызов методов (Control-Freak)
▪ Сервис-локатор (Service Locator)
▪ Обращение зависимости (DI)
▪ Параметры
▪ Dependency Injection + IoC
Асинхронный
▪ Очереди сообщений
Данные
Передача доменных объектов
Объекты передачи данных (DTO)

30.

Должен базироваться на POJO (POCO,
PORO)
Должен поддерживать «из коробки»
Dependency Injection (DI)
Аспект-ориентированное программирование
(АОП)
Интеграция с каркасами модульного
тестирования (JUnit, TestNG, Unitils и т.д.)
Хорошая интеграция с другими каркасами
(JPA, Hibernate, TopLink и т.д).

31.

Монолитное приложение
SOA архитектура
Микросервисы
Интеграция
Удаленный вызов процедур (RPC)
REST
Очереди сообщений

32.

Самое простое решение разместить весь
код системы в одном модуле

33.

Несколько
ограниченных
контекстов в одном
компоненте
Риск
возникновения
зависимостей
между
контекстами

34.

Несколько контекстов
разделяют одну и туже
схему данных
Нарушение SRP
Изменения схемы
данных
необходимые
одному из
контекстов
сказываются на всех

35.

Все контексты находятся в едином репозитории
Много одновременно выполняемой работы
по проекту (Work In Progress (WIP))
Как реализовать новую опцию, если предыдущая
еще не завершена ? Ветвиться ?
Размытие модели (Models Blur)
Код диффундирует из одного контекста в другой
Стремясь избежать дублирования (Don’t Repeat
Yourself (DRY)) программисты смешивают
контексты
▪ Не пытайтесь устранить дублирование. Следите за
изоляцией контекстов

36.

Разделяем систему по вертикали

37.

Для поддержки унаследованного кода
используем концепт пузыря (bubble context)
Bubble Context
Autonomous Bubble Context

38.

Унаследованный код можно выделить как
отдельный сервис

39.

Через разделение данных
База данных
Файловая система
Синхронное взаимодействие
RPC
Simple Object Access Protocol (SOAP)
REST
Асинхронное взаимодействие
Очереди сообщений

40.

41.

42.

Синхронный вызов блокирует вызывающего
клиента
Сбои сети приводят к отказам в
обслуживании
Высокая стоимость масштабирования
Высокий уровень связанности
Логическая связанность (Logical Coupling)
▪ Изменения вызываемого сервиса ломают вызывающий
Временная связанность (Temporal Coupling)
▪ Задержки выполнения на вызываемом сервисе
сказываются на времени ожидания на вызывающем
сервисе

43.

CAP теорема
Распределенные ограниченные контексты
не могут все время находится в
согласованном состоянии
Возможна только эвентуальная
согласованность (Eventual Consistency)
Basically Available, Soft state, Eventual
consistency (BASE)

44.

45.

Технологически сложнее чем RPC
Дороже в реализации
Сложнее найти/подготовить
квалифицированного разработчика
Решение часто зависит от платформы
Большинство внешних систем
поддерживают PRC (SOAP) и/или REST
протоколы взаимодействия
Для интеграции с ними потребуются
дополнительные усилия

46.

Масштабируемость
Доступность
Отказоустойчивость

47.

Основное преимущество – низкая степень
связанности
Декомпозиция контекста на несколько
бизнес компонент
Декомпозиция бизнес компонент
на несколько компонент

48.

49.

Единый транспортный протокол
чаще всего REST
Хореография вместо оркестровки
Преимущества
Быстрая реализация опций
от заказа до рынка