Domain Driven Design

1,186 views

Published on

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

Published in: Technology
  • Be the first to comment

Domain Driven Design

  1. 1. DDD: (Domain-Driven Design) или миром правят три буквы Пинин Денис dpinin@codereign.net
  2. 2. Проблемно-ориентированное проектирование (DDD) (англ. Domain-driven design) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая Wikiped промежуток между реальными условиями области ia применения продукта и кодом. Домен (англ. domain) — область знаний. Область знаний, к которой применяется разрабатываемое программное обеспечение. Модель (англ. model) — описывают отдельные аспекты области и могут быть использованы для решения проблемы. Wikiped Язык описания — используется для единого стиля ia описания домена и модели.
  3. 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. 4. Что было ДО: Бизнес-аналитик Заказчик Бизнесмодель Системный-аналитик, архитектор Модель приложения Разработчик Что стало ПОСЛЕ: Заказчик Разработчик Модель на едином языке
  5. 5. Специалист по предметной области Разработчик
  6. 6. Плюсы модели на едином языке • Единое поле коммуникации для всех участников проекта • Верификация модели заказчиком и выявление наиболее критичных ошибок на этапе постановок • Простота внесения изменений в требования: их не надо перетаскивать через несколько моделей • Гибкость реагирования на ограничения, выявленные при разработке: их можно передать заказчику посредством модели и найти решение
  7. 7. Минусы модели на едином языке • Необходимость понимания модели заказчиком существенно ограничивает моделирование •Технические подробности и сложные формальные методы становятся недоступными • А без них модель не может служить проектом для реализации, нужно дополнительное проектирование
  8. 8. Data Driven vs. Domain Driven Data Driven: Плюсы • Позволяет быстро разработать приложение или прототип • Удобно проектировать (кодогенерация по схеме и тп) • На небольших или средних по размеру проектах может быть вполне себе решением Минусы • Может приводить к анти-паттернам и уходу от ООП • На больших проектах приводит к хаосу, сложной поддержке и т.п.
  9. 9. Data Driven vs. Domain Driven Domain Driven: Плюсы • Использует всю мощь ООП • Позволяет контролировать сложность контекстной области (домена) • Создание доменного языка и внедрение BDD • Дает мощный инструмент для разработки сложных и больших решений Минусы • Требует значительно больше ресурсов при разработке, что приводит к удорожанию решения • Определенные части становятся сложнее в поддержке (мепперы данных и т.п.)
  10. 10. Какие цели мы достигаем с DDD • Откладывание реализации слоя сохранения позволяет реализовать его тогда, когда доменная модель уже спроектирована и реализована, то есть когда она устаканилась. • Слой сохранения реализуется как всего лишь один из инфраструктурных инструментов, а не как жизненно важный слой приложения. Акцент смещается на модель, а не на базу данных и слой доступа к ней. Это дает намного более сильный уровень независимости классов и дает возможность быстро поменять базу данных. • За счет того, что ваш код может жить и без слоя сохранения, его можно намного проще протестировать. Более того, в начале можно написать сначала модель, которую покрыть модульными тестами. • Из предыдущего пункта вытекает то, что если вы апологет TDD, то DDD - это точно ваше. Более подходящий для TDD способ проектирования и разработки приложений сложно себе представить
  11. 11. Кроме всего прочего, Domain Driven Design стимулирует проектировать Rich Domain Model, то есть сущности, которые обладают не только состоянием, но и поведением.
  12. 12. Anemic vs. Rich Domain Model • Простота построения. 90% решений, могут быть построены в данной модели и это будет на порядок дешевле. • Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятственно и идентично сериализован/десериализован между физическими слоями. • Прогнозируемость и управляемость вплоть до DAL. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных. • Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.
  13. 13. Anemic vs. Rich Domain Model • Простота использования. Объекты всегда под рукой. Средства обработки объектов, также под рукой. Использовать Rich – значительно проще, особенно когда в проекте новичок. • Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. Но тут следует упомянуть, что те изменения, которые касаются состояния, также отслеживаются компиляцией со статической типизацией в Anemic, что покрывает большее количество таких проблем. • Меньшее количество мусора в силу более сильной локализации логики.
  14. 14. ORM DDD TDD SOLID
  15. 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. 16. ВОПРОСЫ

×