Учимся проектировать на основе предметной области (DDD: Domain Driven Design)
1. Введение
В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).
2. Так почему же DDD?
Есть несколько шаблонов реализации предметной области (Domain Logic) или бизнес-логики (Business Logic):
1) Table Module – представляет собой объект, в единственном экземпляре, обрабатывающий бизнес логику для всех записей в таблице базы данных, либо представления.
2) Transaction Script – организует взаимодействие с бизнес-логикой посредствам процедур, принимающих запросы с уровня представления.
3) Domain Model – непосредственно, объектная модель предметной области, включающая в себя как поведение, так и данные.
Эти шаблоны описаны более подробно Мартином Фаулером, в его книге “Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений”(Patterns of Enterprise Application Architecture (P of EAA)). В данной книге он показывает, что первые два шаблона более привлекательны в начале работы с предметной областью, однако так же обращает внимание, что при наращивании сложности логики предметной области стоит больше внимания уделять сопровождению инфраструктуры, используя первые два подхода, это время можно уменьшить, если обратиться в своём решении к третьему из вышеперечисленных шаблонов, так называемой “Модели предметной области”.
На основе этого сделаем небольшой вывод о том, что данный шаблон (“Модель предметной области”) лучше всего подойдёт, к примеру, для такой непростой области, как финансовый рынок. Большинство, создаваемого в наши дни программного обеспечения предназначено для различных нужд бизнеса, следовательно какие-то абстрактные, обобщенные решения находят своё место на рынке (с довольно таки высокой конкуренцией) всё реже и реже. К чему я пишу про всё это? Потому что DDD – это не только качественное проектирование, но так же и показательный пример того, как следует выделить предметную область в программном обеспечении, для того, чтобы проще преодолевать сложности, частые изменения, проблемы коммуникации и прочие недуги предметной области, вместо того чтобы разрабатывать уродливую, сложную для понимания систему, в которой любое изменение или исправление способно обрушить на вас лавину всё новых и новых дефектов.
DDD ни в коем случае не отрицает наследия практик разработки, таких как:
DDD лишь дополняет их. Поиск подходящей модели и абстракций в сложных сценариях требует значительных знаний в сфере объектно-ориентированного подхода, и достаточного опыта применения различных принципов, шаблонов и практик, а не просто DDD, как может показаться.
3. С чего можно начать?
Если мой “нудный PR” проектирования на основе предметной области (DDD) вас до сих пор не утомил, то думаю нам стоит продолжить, если же иначе, то посмотрите хотя бы ссылки на материалы.
Книга довольна подробно рассказывает о том, что из себя представляет DDD, и все связанные аспекты, такие как: язык предметной области, шаблоны, практики проектирования, рефакторинг, моделирование, как сделать разработку гибкой и многое другое. Но даже если вы ознакомитесь со всеми вопросами, поднятыми в книге (что является не совсем простым занятием), вы обратите внимание, что вопросы рассматриваются только с теоретической точки зрения, оставляя весь простор для практики (книга не привязана к конкретной платформе разработки). Для большинства из нас чтение чистой теории, без подкрепления практическими примерами не нравится, в связи с этим можно обратить своё внимание на сокращенную (и свободную для доступа) версию этой книги, подготовленную порталом InfoQ: Domain Driven Design Quickly.
Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:
1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода
2) Как организовывать архитектурные слои в своих решениях
3) Как применять шаблоны и практики DDD
4) Как построить небольшой каркас для DDD
5) Как изолировать домен предметной области от модели
6) Современные паттерны представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight) в практики.
Эта книга – отличный практикум по DDD, содержащий очень широкий пласт идей. Начинается книга с разработки требований, а заканчивается реализацией промышленного приложения, исходные коды которого доступны на Codeplex.
Вся концепция книги построена на 3 книгах-столпах DDD:
В этой книге поверхностно рассмотрены все вопросы, техники и паттерны, применяемые в DDD, все примеры сопровождаются кодом, что упрощает понимание. Книга превосходная, однако русский перевод подкачал, поэтому, рекомендую прочитать оригинал.
Однако DDD – это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо учитывать, если вы решили следовать DDD, таких как: фокусирование на высокий приоритет отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д…это является основной причиной ознакомиться с книгой Эрика Ивенса, так как она даст вам более объемное и глубокое понимание философии DDD.
DDD не привязанны к конкретной технологии, однако соблюдать DDD будет не так просто, без наличия хороших средств и практик в вашем арсенале, таких как: TDD-фреймворк, ORM, возможность реализации независимости сохраняемости (Persistence Ignorance), IoC-контейнер (Inversion of Control), и возможностей AOP (Аспектно-Ориентированного Программирования), конечно не значит, что все эти инструменты нам понадобятся, однако они приблизят нас к реализации DDD на практике. Практичная ценность этих средств в том, что они позволять изолировать модель предметной области, что является ключевой целью DDD. Книга Джимми Нильссона может познакомить вас с возможностями и видами данных инструментов. Джимми так же показывает как использовать шаблоны реализации корпоративных приложений, и строить, благодаря им, цельное решение, основанное на современных инструментах и практиках.
Некоторые реализации шаблонов DDD на Ruby On Rails:
C DDD так же тесно связана такая тема, как DDDD: Distributed Domain Driven Design (Распределенный DDD). DDDD – это DDD в распределенных сценариях. В настоящее время существует не так много ресурсов, посвященных DDDD, в нескольких словах о DDDD: покрывает проблему реализации сообщений и DDD, разделение команд и запросов (Command Query Separation (CQS)) помогает реализовать данный подход. Грег Янг (Greg Young) сообщил, что готовит книгу, посвященную DDDD.
SOA и DDD – это ещё одна объемная тема, часто обсуждаемая Udi Dahan
Найти хорошие примеры реализации DDD очень сложно, не потому что их не существует, а потому что реальная сила DDD реализуется в приложениях, используемых в довольно сложных областях, и, как правило, являющихся коммерческими проектами. Однако можно найти несколько неплохих проектов, в которых можно проследить некоторые идеи реализации шаблонов DDD.
Вот они:
1) Приложение Тима Маккарти его проект, описанный в деталях в его книге. Он описывает не только применение шаблонов, но так же акцентирует внимание в разработке модели предметной области с точки зрения DDD.
Проект так же интересен тем, что построен на .NET 3.5 и демонстрирует всю силу современного подхода связывания данных с моделью предметной области (data binding, реализация шаблона MVVM). Так же его стиль примечателен умением выделять абстракции и повторно используемый код.
2) Следующий проект, на который следует обратить внимание – это приложение разработанное Yves Goeleven, создание данного приложения описано в его блоге (так же посвященному основным концептам DDD). Другим его приложением является DDD-каркас. Следует обратить внимание на его реализацию взаимодействия шаблонов Repository и Specification.
3) Billy McCafferty разрабатывает потрясающий open source фреймворк, сфокусированный на DDD, под названием S#arp Architecture. У него есть очень хорошее описание, включающее в себя описание шаблонов и подходов, заключенных в фреймворке. Фреймворк нацелен на разработку ASP.NET MVC приложений с применением NHibernate.
4) C# Domain-Driven Design sample application ( ndddsample ), это приложение, разрабатываемое Джимми Нильссоном, демонстрирует разбиение приложения на ключевые слои с точки зрения DDD. Так же демонстрируется практическое применение шаблонов building block в предметной области перевозки грузов, описанной в его книге.
Этот проект основан на совместной работе компании Эрика Ивенса “Domain Language” и шведской консалтинговой компании “Citerus”.
Цель этого проекта:
Показать практическое применение использования DDD с применением .NET.
Использование актуальных утилит, технологий и методологий разработки в области .NET, обсуждаемыхALT.NET-коммунити.
Привести практические примеры реализации типовых DDD приложений.
Показать способ реализации DDD на конкретной платформе, что позволит без труда осуществить тоже самое на любой другой платформе.
Помочь в выборе реализуемых практик. Различные подходы позволят сообществу обсудить их и выбрать соответствующий для конкретной реализации.
Группа обсуждений - http://tech.groups.yahoo.com/group/domaindrivendesign/ это взрослая группа, очень хороший источник идей, место для обсуждений всех видов проблем в области DDD. В ней на ваши вопросы могут ответить опытные в DDD люди, даже Эрик Ивенс :-).
Если вы заинтересованы в расширении ваших “объектно-ориентированных горизонтов” в сложных корпоративных системах и изучении новых способов разработки и проектирования, то DDD – именно то что нужно.
Виталий, очень понравилась статья! PR удался на славу жаль, что в блоге всего три записи=) с нетерпением ждём новых!
так уж вышло, что сегодня эту статью показали студенты на консультации. Она их безмерно воодушевила, но и здорово смутила. В связи с этим предложение
>В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями не добавить ли определение DDD хотя бы в комментарии? не отметить ли место DDD в области знаний о программной инженерии? например в рамках классификации SWEBOK? Читающий может оказаться в недоумении: DDD - шаблон? подход? набор эвристик или лучших практик? технология? методология? методика проектирования-программирования-разработки в целом (в статье периодически рядом встречаются и design и development)? если проектирования, то какого уровня - концептуального-логического-физического-итд -вдруг всех сразу? и если проектирования, то чего - модели предметной области, некоторого уровня архитектуры системы, требований?
По-моему DDD - это ненужный наворот, раздутый из пустого места. да, надо больше внимания уделять предметной области при проектировании. Да, с неё всё и начаинается. ну и что? зачем столько шума-то раздувать? 2 Ellene чо за консультация ночью?
Столько вопросов ;) На счёт определения места DDD в науке я знаниями не располагаю, но считаю, что это скорее практическая методология/подход к проектированию, разработке, программированию, основным акцентом которой является построение модели предметной области, остальные же слои приложения на архитектурном уровне так же попадают под влияние этой методологии, т.к. приходится учитывать особенности более высокого уровня абстракции. teamspeak виртуальная реальность - что это? можно ссылочку?
Виталий, да это не про DDD. Это насчёт того, что консультация к экзамену у нас проходила виртуально - при помощи team speak =) http://www.teamspeak.com/
На самом деле хватает книжки "Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений", но в DDD есть хорошие идеи и мы с удовольствием применяем их в своих проектах.
Очень это ты здорово и правильно написал. Давно уже нам пора дорасти до этой темы. Докладик не хочешь сделать?
Я и сам подсел недавно на DDD (пока только теоретически), очень хорошо его изучать по блогу Casey Charlton’а, а Udi -- это уже для джедаев, по-моему.
Кстати, Udi, кажется, писал, что те, кто начинает осваивать DDD, ворчат, что мы и сами это делаем, все эти Domain Layer и Repository, ничего тут у вас нового нет. А потом начинается продвинутый DDD stuff, и там очень даже нового есть. Это @Maxx.
Еще стоит заметить, что все вводные в DDD начинаются с понятий Domain Expert и Ubiquitous Language. Без этого, говорят, хоть вы десять слоев на паттерны накрутите, а DDD это называться не будет. То есть, еще до того, как вы начнете проектировать, должен быть дядя от заказчика, с которым вы сядете и выработаете язык для описания домена. А заканчиваются все обучалки предостережением, что DDD годится далеко не для всех задач. Хотя, в некоторых проектах можно успешно применять некоторые идеи DDD.
Книжка Эванса -- это классика, позор, что ее не перевели у нас. После этого поста, может быть, переведут..
Спасибо! Думаю, что доклад будет, но надо приложение закончить, по которому буду рассказывать, без практики скучно, с практикой быстрее входишь во вкус.
@ulu "еще до того, как вы начнете проектировать, должен быть дядя от заказчика, с которым вы сядете и выработаете язык для описания домена" У вас это происходило в реальности или это только теория?
@Alexander Byndyu Только теория http://www.simplyvinay.com/Post/48/A-...ssion.aspx "..a DDD example done without an external domain expert probably isn't a good idea. A few of us have tried this over the years and decided it wasn't a great idea.." "I don't think it suits full DDD no, because you need domain experts and a complex enough problem domain to justify it.."
@ulu Если вдруг удастся попробовать это на практике, расскажите как отреагировал заказчик, какие возникли проблемы и как все прошло! Будет интересно ;)
@Alexander Byndyu "дядя от заказчика", это роль. не всегда это реально человек _работающий_ в другой компании - заказчике ( да и не всегда у приложения есть сторонний заказчик - есть коробочные продукты )
"дядя от заказчика" - в другой терминологии чтото близкое к аналитику, человек не пишуший код, а думающий о проблемах.
Интересно, я у кого-то из гуру читал, что как раз коробочные решения не очень подходят для DDD -- и именно из-за того, что там нет доменного эксперта. Может, это буквоедство, конечно? Или все-таки важно, чтобы он был посторонний? Похоже, что человек дожен быть из бизнеса, для которого делается приложение, а не из фирмы-разработчика?
Интересно, что DDD -- это не просто набор паттернов програмирования, как програмистам хотелось бы видеть, а целостный процесс, включающий в себя вещи, не связанные со стучанием по клавишам..
Комментариев нет:
Отправить комментарий