Embed Size (px)
DESCRIPTION
DDD: (Domain-Driven Design) или миром правят три буквы
Citation preview
Проблемно-ориентированное проектирование (DDD) (англ. Domain-driven design) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями области применения продукта и кодом.
Wikipedia
Домен (англ. domain) — область знаний. Область знаний, к которой применяется разрабатываемое программное обеспечение.Модель (англ. model) — описывают отдельные аспекты области и могут быть использованы для решения проблемы.Язык описания — используется для единого стиля описания домена и модели.
Wikipedia
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans• на английском – в 2003 г.• на русском – в 2010 г.
DDD – как оно начиналось
Applying Domain-Driven Design and Patterns with Examples in C# and .NETby Jimmy Nilsson
• на английском – в 2006 г.
• на русском – в 2007 г.
Что было ДО:
Что стало ПОСЛЕ:
Разработчик
Разработчик
Заказчик
Заказчик
Бизнес-аналитикСистемный-аналитик,
архитектор
Бизнес-модель
Модельприложения
Модель на едином языке
РазработчикСпециалист попредметной области
Плюсы модели на едином языке
• Единое поле коммуникации для всех участников проекта• Верификация модели заказчиком и выявление наиболее критичных ошибок на этапе постановок• Простота внесения изменений в требования: их не надо перетаскивать через несколько моделей• Гибкость реагирования на ограничения, выявленные при разработке: их можно передать заказчику посредством модели и найти решение
Минусы модели на едином языке
• Необходимость понимания модели заказчиком существенно ограничивает моделирование •Технические подробности и сложные формальные методы становятся недоступными• А без них модель не может служить проектом для реализации, нужно дополнительное проектирование
Data Driven vs. Domain Driven
Плюсы• Позволяет быстро разработать
приложение или прототип• Удобно проектировать (кодогенерация
по схеме и тп)• На небольших или средних по размеру
проектах может быть вполне себе решением
Минусы• Может приводить к анти-паттернам и
уходу от ООП• На больших проектах приводит к
хаосу, сложной поддержке и т.п.
Data Driven:
Domain Driven:
Data Driven vs. Domain Driven
Плюсы• Использует всю мощь ООП• Позволяет контролировать сложность
контекстной области (домена)• Создание доменного языка и
внедрение BDD• Дает мощный инструмент для
разработки сложных и больших решений
Минусы• Требует значительно больше ресурсов
при разработке, что приводит к удорожанию решения
• Определенные части становятся сложнее в поддержке (мепперы данных и т.п.)
Какие цели мы достигаем с DDD• Откладывание реализации слоя сохранения позволяет реализовать его тогда, когда доменная модель уже спроектирована и реализована, то есть когда она устаканилась.
• Слой сохранения реализуется как всего лишь один из инфраструктурных инструментов, а не как жизненно важный слой приложения. Акцент смещается на модель, а не на базу данных и слой доступа к ней. Это дает намного более сильный уровень независимости классов и дает возможность быстро поменять базу данных.
• За счет того, что ваш код может жить и без слоя сохранения, его можно намного проще протестировать. Более того, в начале можно написать сначала модель, которую покрыть модульными тестами.
• Из предыдущего пункта вытекает то, что если вы апологет TDD, то DDD - это точно ваше. Более подходящий для TDD способ проектирования и разработки приложений сложно себе представить
Кроме всего прочего, Domain Driven Design стимулирует проектировать Rich Domain Model, то есть сущности, которые обладают не только состоянием, но и поведением.
Anemic vs. Rich Domain Model• Простота построения. 90% решений, могут быть построены в данной модели и это будет на порядок дешевле.• Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятственно и идентично сериализован/десериализован между физическими слоями.• Прогнозируемость и управляемость вплоть до DAL. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных.• Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.
• Простота использования. Объекты всегда под рукой. Средства обработки объектов, также под рукой. Использовать Rich – значительно проще, особенно когда в проекте новичок.• Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. Но тут следует упомянуть, что те изменения, которые касаются состояния, также отслеживаются компиляцией со статической типизацией в Anemic, что покрывает большее количество таких проблем.• Меньшее количество мусора в силу более сильной локализации логики.
Anemic vs. Rich Domain Model
DDDORMTDD
SOLID
Дополнительно почитать о 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-implementation/
ВОПРОСЫ
