DDD: (Domain-Driven Design) или миром правят три буквы

1. DDD:
(Domain-Driven Design)
или миром правят три буквы
Пинин Денис
dpinin@codereign.net

2. Проблемно-ориентированное проектирование (DDD)
(англ. Domain-driven design) — это набор принципов и
схем, помогающих разработчикам создавать изящные системы
объектов.
При правильном применении оно приводит к созданию
программных абстракций, которые называются
моделями предметных областей.
В эти модели входит сложная бизнес-логика, устраняющая
Wikiped
промежуток между реальными условиями области ia
применения продукта и кодом.
Домен (англ. domain) — область знаний. Область знаний, к
которой применяется разрабатываемое программное
обеспечение.
Модель (англ. model) — описывают отдельные аспекты
области и могут быть использованы для решения
проблемы.
Wikiped
Язык описания — используется для единого стиля ia
описания домена и модели.

3. DDD – как оно начиналось
Domain-Driven Design:
Tackling Complexity in the Heart of Software
by Eric Evans
• на английском – в 2003 г.
• на русском – в 2010 г.
Applying Domain-Driven Design
and Patterns with Examples in C#
and .NET
by Jimmy Nilsson
• на английском – в 2006 г.
• на русском – в 2007 г.

4. Что было ДО:
Бизнес-аналитик
Заказчик
Бизнесмодель
Системный-аналитик,
архитектор
Модель
приложения
Разработчик
Что стало ПОСЛЕ:
Заказчик
Разработчик
Модель на едином языке

5. Специалист по
предметной области
Разработчик

6. Плюсы модели на едином языке
• Единое поле коммуникации для всех участников проекта
• Верификация модели заказчиком и выявление наиболее
критичных ошибок на этапе постановок
• Простота внесения изменений в требования: их не надо
перетаскивать через несколько моделей
• Гибкость реагирования на ограничения, выявленные при
разработке: их можно передать заказчику посредством модели
и найти решение

7. Минусы модели на едином языке
• Необходимость понимания модели заказчиком
существенно ограничивает моделирование
•Технические подробности и сложные
формальные методы становятся недоступными
• А без них модель не может служить проектом
для реализации, нужно дополнительное
проектирование

8. Data Driven vs. Domain Driven
Data Driven:
Плюсы
• Позволяет быстро разработать приложение или
прототип
• Удобно проектировать (кодогенерация по схеме
и тп)
• На небольших или средних по размеру проектах
может быть вполне себе решением
Минусы
• Может приводить к анти-паттернам и уходу от
ООП
• На больших проектах приводит к
хаосу, сложной поддержке и т.п.

9. Data Driven vs. Domain Driven
Domain Driven:
Плюсы
• Использует всю мощь ООП
• Позволяет контролировать сложность
контекстной области (домена)
• Создание доменного языка и внедрение BDD
• Дает мощный инструмент для разработки
сложных и больших решений
Минусы
• Требует значительно больше ресурсов при
разработке, что приводит к удорожанию решения
• Определенные части становятся сложнее в
поддержке (мепперы данных и т.п.)

10. Какие цели мы достигаем с DDD
• Откладывание реализации слоя сохранения позволяет реализовать его
тогда, когда доменная модель уже спроектирована и реализована, то
есть когда она устаканилась.
• Слой сохранения реализуется как всего лишь один из
инфраструктурных инструментов, а не как жизненно важный слой
приложения. Акцент смещается на модель, а не на базу данных и слой
доступа к ней. Это дает намного более сильный уровень независимости
классов и дает возможность быстро поменять базу данных.
• За счет того, что ваш код может жить и без слоя сохранения, его
можно намного проще протестировать. Более того, в начале можно
написать сначала модель, которую покрыть модульными тестами.
• Из предыдущего пункта вытекает то, что если вы апологет TDD, то
DDD - это точно ваше. Более подходящий для TDD способ
проектирования и разработки приложений сложно себе представить

11. Кроме всего прочего, Domain Driven
Design стимулирует проектировать Rich
Domain Model, то есть сущности, которые
обладают не только состоянием, но и
поведением.

12. Anemic vs. Rich Domain Model
• Простота построения. 90% решений, могут быть построены в
данной модели и это будет на порядок дешевле.
• Бизнес-объекты – отчуждаемы. В результате, бизнес-объект
может быть спокойно пронесен от DAL, к фасаду и даже далее.
Беспрепятственно и идентично сериализован/десериализован
между физическими слоями.
• Прогнозируемость и управляемость вплоть до DAL. В
случае, если вы ворочаете большими объемами данных, в
Anemic вам проще управлять запросами к базе данных, чем в
Rich. База данных была и остается самой тяжелой частью
бизнес приложений. Оптимизация в основном достигается за
счет повышения эффективности работы с базой данных.
• Бизнес-объект проще управлять объектами, которые еще не
полностью в валидированном состоянии. В Rich – наличие
валидаторов обязывает держать валидированное состояние. Во
многом, бизнес-объект больше похож на данные, чем на объект
в стиле объектного программирования.

13. Anemic vs. Rich Domain Model
• Простота использования. Объекты всегда под рукой.
Средства обработки объектов, также под рукой.
Использовать Rich – значительно проще, особенно
когда в проекте новичок.
• Инкапсуляция. Программисту, использующему
данный объект, недоступно его состояние, кроме как
определенный интерфейс. Это локализует некоторые
изменения в логике. Но тут следует упомянуть, что те
изменения, которые касаются состояния, также
отслеживаются компиляцией со статической
типизацией в Anemic, что покрывает большее
количество таких проблем.
• Меньшее количество мусора в силу более сильной
локализации логики.

14. ORM
DDD
TDD
SOLID

15. Дополнительно почитать о DDD можно в умных
книжках:
• Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart
of Software
• Jimmy Nilsson. Applying Domain-Driven Design and Patterns: With
Examples in C# and .NET
• Tim McCarthy. .NET Domain-Driven Design with C#: Problem Design - Solution (Programmer to Programmer)
И в онлайне:
• http://domaindrivendesign.org/
• http://hinchcliffe.org/archive/2005/03/20/189.aspx
• http://www.emxsoftware.com/Domain+Driven+Design/
• http://www.infoq.com/articles/ddd-in-practice
• http://www.udidahan.com/2007/03/06/better-domain-driven-design-

16. ВОПРОСЫ