2. Что?
Проблемно-ориентированное проектирование
«Набор принципов и схем, помогающих
разработчикам создавать изящные
системы объектов.»
Wikipedia
Чем не является?
●
RAD
Обилие связующего кода, десятки
вспомогательных объектов и тд.
●
Серебряной пулей
Подходит не для всех бизнес приложений.
3. Где?
Бизнес
ERP, CRM, MDM, EAM,
SCM и другие умные
абривиатуры.
Сервисы
Совместная разработка,
онлайн-офис, agile
инструменты.
Игры
Сервера массовых
многопользовательских
онлайн-игр.
4. Когда?
●
Обилие бизнес-процессов
Не CRUD приложение.
●
Доступ к эксперту в предметной области
Skype'а может быть не достаточно.
●
Квалифицированная команда
Умение применять: шаблоны проектирования; модульные тесты; CI.
5. Symfony 2 как основа для
DDD приложения
●
Контейнер зависимостей
Принцип инверсии зависимостей — ключевой элемент хорошей архитектуры
●
Doctrine ORM
DataMapper, Events, Table Inheritance
●
Множество готовых абстракций
EventDispatcher, Form, Request, User
●
Сообщество
FOSRestBundle, JMSSerializer, NelmioApiDocBundle
6. Каноничный подход к архитектуре
Symfony 2 приложения
●
Бандлы как готовое приложение
Бизнес-правила связаны с фреймворком?
●
Анемичная доменная модель
Объекты без поведения. Структуры?
●
Бизнес-логика в сервисах
Объекты без ограничения ответственности?
●
«Жесткая» конфигурация DIC
Нет параметров. Не используются alias.
Почему так? KISS!
7. Каноничный подход к архитектуре
Symfony 2 приложения
Бандлы как готовое приложение
8. DDD подход к архитектуре
Symfony 2 приложения
Бандлы как средство интеграции
Бандл предоставляет реализации
интерфейсов домена в рамках
текущего приложения.
9. DDD подход к архитектуре
Symfony 2 приложения
Бандлы как средство интеграции
Doctrine ORM не умеет
связывать (пока) объекты
значения.
Решение:
●
●
●
Использовать lifecycle callbacks;
PostLoad — для десериализации
столбцов базы в объект-значение
PrePersist и PreUpdate — для
сериализации объекта
10. Каноничный подход к архитектуре
Symfony 2 приложения
Анемичная доменная модель
11. DDD подход к архитектуре
Symfony 2 приложения
Насыщенная модель предметной области
12. DDD подход к архитектуре
Symfony 2 приложения
Насыщенная модель предметной области
●
●
Единый язык — наименование объектов и методов домена
имеют смысл для эксперта предметной области.
Нет get* и set* методов.
Building an Object Model: No setters allowed
●
Объекты-значения — свойства, важные в той предметной
области, которую вы моделируете.
Mathias Verraes: Money
●
Сущности защищены от стороннего кода
Mathias Verraes: Unbreakable Domain Models
13. Каноничный подход к архитектуре
Symfony 2 приложения
Бизнес-логика в сервисах
Вопрос: где должен быть метод createOrder?
14. DDD подход к архитектуре
Symfony 2 приложения
Сервисы как посредники между API и доменом
*Command классы — DTO для API данных.
Метод createOrder теперь располагается только в OrderService.
15. API для DDD приложения
●
Отдельный бандл
CoreDomain — CoreApiBundle.
●
Контроллеры как сервисы
Больше гибкости для UI.
●
CQRS — разделение
моделей чтения и записи
Account — AccountView
Order — OrderView
16. API для DDD приложения
REST — наш выбор!
●
Любые клиенты;
Браузер, мобильной приложение,
телевизор, чайник ...
●
Простота реализации;
еще проще с FOSRestBundle.
●
Документация;
NelmioApiDocBundle — поможет!
17. UI для DDD приложения
●
Отдельный бандл
CoreDomain — CoreViewBundle.
●
Формы — это часть UI
Формы соответствуют API командам,
а не доменным объектам.
●
JS MVC — это удобно!
Backbone, AngularJS, EmberJS,
KnockoutJS.
18. Идеи на будущее
●
●
●
●
Doctrine 2.5 — поддержка объектов-значений.
Zephir — для доменов со сложной
алгоритмикой.
DDD Serializer — сериализация в терминах
DDD.
???