Писать программы легко — во всяком случае, с нуля. Но изменить однажды написанный программный код, который создали другие разработчики или вы сами каких-то шесть лет тому назад, — гораздо сложнее. Программа работает, но вы не знаете точно, как именно. Даже обращение к экспертам в предметной области ничего не дает, поскольку в коде не сохранилось никаких следов привычного для них языка.Предметно-ориентированное проектирование (Domain-Driven Design, DDD) — это процесс тесной увязки программного кода с реалиями предметной области.Благодаря ему добавление в программный продукт новых возможностей по мере его развития становится таким же простым, как и при создании программы с нуля. Эта книга в полной мере соответствует философии DDD и позволяет разработчикам перейти от философских рассуждений к решению практических задач.
Пространство задачи
Прежде чем приступать к разработке решения, следует понять поставленную задачу. DDD подчеркивает необходимость вникнуть в предметную область бизнес-задачи — разобраться в ее терминологии, выявить глубинные причины, стоящие за потребностью в разработке программного обеспечения, и понять, что является успехом с позиций бизнеса. Жизненно важно, чтобы такое владение темой стало для разработчиков столь же ценным и ценимым качеством, как технические знания и опыт: это дает возможность глубже понять предметную область и помогает разделить большую область на более мелкие части.
На рис. В.1 представлен общий вид пространства задачи (problem space) в DDD, о котором рассказывается в первой части книги.
Пространство решений
Составив ясное представление о предметной области, вы сможете с помощью стратегических шаблонов DDD реализовать техническое решение, согласованное с предметной областью. Стратегические шаблоны позволяют оградить основные части системы, крайне важные для успеха продукта, от влияния неспециализированных областей. Благодаря изоляции неотъемлемых компонентов системы их последующие изменения не отразятся рикошетом на остальной системе.
В основе тех ключевых подсистем вашего продукта, которые достаточно сложны или будут часто изменяться, должна лежать модель. Тактические шаблоны DDD вкупе с архитектурой на основе модели (Model-Driven Design) помогут вам создать полезную модель предметной области в коде. Модель — это вместилище всей той прикладной логики, благодаря которой приложение выполняет все бизнес-сценарии использования. Модель отделена от технических сложностей, что оставляет простор для развития и изменения бизнес-правил и регламентов. Модель, согласованная с предметной областью, сделает ваше программное обеспечение легко адаптируемым и понятным для других разработчиков и специалистов со стороны бизнеса.
На рис. В.2 представлен общий вид пространства решений (solution space) DDD, о котором также рассказывается в первой части книги.
Структура этой книги
Часть I. Принципы и приемы предметно-ориентированного проектирования
Часть I знакомит вас с принципами и приемами DDD.
Глава 1. Что такое предметно-ориентированное проектирование?
DDD — это методология, помогающая справляться с проблемами, которые возникают при создании программного обеспечения для сложных предметных областей. Первая глава представляет философию DDD и рассказывает о том, почему терминология, сотрудничество и контекст являются самыми важными аспектами DDD и почему DDD — это гораздо больше, чем просто набор шаблонов программирования.
Глава 2. Дистилляция предметной области задачи
Освоение сложной предметной области чрезвычайно важно для создания удобного в сопровождении программного обеспечения. Процесс переработки знаний с участием экспертов в предметной области является ключом к этим знаниям. Глава 2 подробно рассказывает о приемах, которые позволяют команде разработчиков и экспертам в предметной области сотрудничать, совместно экспериментировать и обучаться, чтобы создавать эффективные модели предметной области.
Глава 3. Концентрация на смысловом ядре
В главе 3 рассказывается, как выполнить дистилляцию большой предметной области и выявить наиболее важную часть задачи — смысловое ядро (core domain). Затем мы объясняем, почему время и силы следует тратить прежде всего на смысловое ядро, изолировав его от менее важных областей поддержки (supporting domains) и неспециализированных областей (generic domains).
Глава 4. Проектирование на основе модели
Коллеги из бизнеса владеют аналитической моделью (analysis model) предметной области. У разработчиков есть собственная версия этой модели — программная модель (code model). Однако для успешного сотрудничества двух команд — разработчиков и специалистов от бизнеса — необходима единая модель. Единый язык (ubiquitous language) и разделяемое всеми представление о пространстве задачи — вот что связывает аналитическую модель с программной моделью. Идея единого языка является центральной для DDD и служит основой всей методологии. Единый язык для описания терминов и понятий предметной области, совместно выработанный командой разработчиков и бизнес-экспертами, крайне необходим для обсуждения сложных систем.
Глава 5. Шаблоны реализации предметной модели
Глава 5 представляет собой развернутый рассказ о том, за что отвечает и какую роль играет в приложении модель предметной области (domain model). Здесь представлены также различные шаблоны, которые можно применять при реализации модели предметной области, и описаны ситуации, для которых они являются наиболее подходящими.
Глава 6. Обеспечение целостности моделей предметной области с помощью ограниченных контекстов
В крупных решениях может существовать более одной модели. Важно сохранить целостность каждой модели, чтобы избежать неоднозначностей в языке и ненадлежащего использования понятий различными командами. Стратегический шаблон под названием «ограниченный контекст» (bounded context) создан специально для того, чтобы изолировать и защитить модель в контексте, обеспечив при этом возможность ее совместной работы с другими моделями.
Глава 7. Карты контекстов
Карта контекстов (context map), которая используется для того, чтобы понять и отразить отношения между разными моделями в приложении и способы их интеграции, является критически важным элементом стратегического проектирования. Карты контекстов охватывают не только технические аспекты интеграции, но и политические отношения между командами. Они дают общую картину ландшафта, которая помогает командам понять свою модель в контексте ландшафта в целом.
Глава 8. Архитектура приложения
Приложение должно уметь использовать модель предметной области, чтобы отвечать требованиям бизнес-сценариев использования. Глава 8 знакомит вас с архитектурными шаблонами, позволяющими структурировать приложение таким образом, чтобы сохранить целостность модели предметной области.
Глава 9. Типичные проблемы команд, начинающих применять предметно-ориентированное проектирование
Глава 9 описывает характерные сложности, с которыми сталкиваются команды, применяющие DDD, и рассказывает, почему так важно знать, когда этот подход применять не следует. Здесь объясняется также, почему мощный инструментарий DDD в приложении к простым задачам может порождать избыточные и неоправданно усложненные системы.
Глава 10. Применение принципов, приемов и шаблонов DDD
Глава 10 повествует о том, как убедить других в преимуществах DDD и начать применять принципы и приемы этого подхода в своих проектах. Здесь объясняется, почему попытки создать идеальную модель предметной области не так ценны для создания качественного программного обеспечения, как исследования и эксперименты.
Часть II. Стратегические шаблоны: взаимодействие ограниченных контекстов
Часть II показывает, как интегрировать ограниченные контексты, и подробно описывает возможные подходы к конструированию ограниченных контекстов. Здесь представлены примеры кода, демонстрирующие тонкости интеграции с существующими приложениями, и описаны приемы, которые позволяют обеспечить коммуникацию через границы контекстов.
Глава 11. Введение в интеграцию ограниченных контекстов
Современные приложения — это распределенные системы, от которых требуются надежность и масштабируемость. Эта глава сводит воедино теорию распределенных систем и DDD, чтобы вы могли взять лучшее из обоих миров.
Глава 12. Интеграция посредством обмена сообщениями
Здесь мы в качестве иллюстрации создаем приложение, которое на примере организации шины сообщений для асинхронного обмена сообщениями показывает, как принципы построения распределенных систем применяются совместно с DDD.
Глава 13. Интеграция с RPC и REST посредством HTTP
Еще один пример приложения, демонстрирующий альтернативный подход к созданию асинхронных распределенных систем: вместо шины сообщений используются стандартные протоколы, такие как протоколы HTTP (протокол передачи гипертекста — Hypertext Transport Protocol), REST и Atom.
Часть III. Тактические шаблоны: создание эффективных моделей предметной области
Часть III охватывает шаблоны проектирования, которые можно использовать для построения модели предметной области в программном коде, наряду с шаблонами обеспечения сохранности модели и шаблонами управления жизненным циклом объектов предметной области, образующих модель.
Глава 14. Знакомство со стандартными блоками моделирования предметной области
Эта глава знакомит вас со всеми тактическими шаблонами, которые имеются в вашем распоряжении и позволяют создавать эффективные модели предметной области.
Приведенные здесь практические рекомендации помогают получать более управляемые и выразительные модели в программном коде.
Глава 15. Объекты-значения
Глава 15 служит введением в объекты-значения (value objects) — моделирующие конструкции DDD, которые позволяют представить такие лишенные индивидуальности понятия предметной области, как деньги.
Глава 16. Сущности
Сущности (entities) — это понятия предметной области, обладающие идентичностью, такие как клиенты, транзакции и отели. Эта глава содержит множество примеров и охватывает ряд дополнительных шаблонов реализации.
Глава 17. Службы предметной области
Некоторые понятия предметной области представляют собой операции без фиксации состояния, не относящиеся к каким-либо объектам-значениям или сущностям. Они известны как службы предметной области (domain services).
Глава 18. События предметной области
Во многих предметных областях можно достичь более глубокого понимания, если не ограничиваться исследованием одних лишь сущностей, а обратить пристальное внимание на события (events). В этой главе представлен шаблон проектирования на основе событий предметной области, который позволяет более ясно отражать события в модели предметной области.
Глава 19. Агрегаты
Агрегаты (aggregates) — это совокупности объектов, представляющих понятия предметной области. По сути дела, агрегаты ограничивают зону согласованности вокруг инвариантов. Это наиболее мощный из тактических шаблонов.
Глава 20. Фабрики
Фабрики (factories) — это шаблон организации жизненного цикла, который отделяет конструирование сложных объектов предметной области от их использования.
Глава 21. Репозитории
Репозитории (repositories) выступают посредниками между моделью предметной области и моделью данных. Они обеспечивают изоляцию модели предметной области от любых инфраструктурных особенностей и задач.
Глава 22. Регистрация событий
Регистрация событий (event sourcing), как и сами события, о которых рассказывается в главе 18, представляет собой полезный прием, который позволяет делать в программном коде акцент на событиях, возникающих в предметной области. Регистрация событий представляет собой шаг за пределы событий предметной области, поскольку сохраняет в виде событий состояние модели предметной области. Эта глава включает в себя целый ряд примеров, в том числе такие примеры, где используется специализированное хранилище событий.
Часть IV. Шаблоны проектирования эффективных приложений
В части IV представлены шаблоны для конструирования приложений, использующие модель предметной области и защищающие ее целостность.
Глава 23. Конструирование пользовательских интерфейсов приложения
Пользовательский интерфейс системы, состоящей из множества ограниченных контекстов, часто требует комбинирования данных из нескольких контекстов, особенно когда ограниченные контексты образуют распределенную систему.
Глава 24. CQRS: архитектура ограниченного контекста
CQRS (Command Query Responsibility Segregation — разделение ответственности на команды и запросы) — это шаблон проектирования, создающий две модели на месте одной. Там, где прежде была единая модель, обрабатывающая два разных контекста чтения и записи, создаются две отдельные модели — для обработки команд и для обслуживания запросов, на основе которых формируются отчеты.
Глава 25. Команды: шаблоны прикладных служб для обработки бизнес-сценариев использования
Здесь описываются различия между прикладной и предметной логикой. Имея ясное представление об этих различиях, вы сумеете уберечь свою модель от расползания и упростить сопровождение системы.
Глава 26. Запросы: предметная отчетность
Чтобы принимать обдуманные решения в отношении разработки продукта и в деловой сфере, бизнес-специалистам нужна информация. В этой главе демонстрируются многочисленные приемы создания отчетов, обеспечивающих требуемый уровень информирования бизнеса.
Кому адресована эта книга
Основные темы DDD — приемы, шаблоны и принципы — обсуждаются здесь наряду с личным опытом и трактовкой методологии. Цель книги — помочь тем, кто заинтересовался этим подходом или только приступает к его использованию. Она не заменяет собой книгу «Предметно-ориентированное проектирование» Эрика Эванса1, однако просто и доходчиво излагает концепции, введенные Эвансом, сопровождая описание практическими примерами, — с тем чтобы любой разработчик мог быстро войти в курс дела, прежде чем приступить к более глубокому изучению этой методологии.
В основе книги лежит личный опыт автора, полученный при использовании предмета обсуждения. Специалисты с большим опытом применения DDD могут в чем-то не согласиться с автором, но даже они, вероятно, смогут почерпнуть отсюда что-то полезное для себя.
Об авторе
Скотт Миллетт (Scott Millett) — директор по информационным технологиям компании Iglu.com. Использует .NET, начиная с версии 1.0. В 2010 и 2011 годах был удостоен награды ASP.NET MVP Award. Является также автором книги «Professional ASP.NET Design Patterns and Professional Enterprise .NET».
О соавторе
Ник Тьюн (Nick Tune) со страстной увлеченностью решает задачи, возникающие перед бизнесом, создает впечатляющие программные продукты и непрестанно учится. Создание программного обеспечения — это работа его мечты. Пока что самым ярким этапом его карьеры была работа в 7digital, где он входил в состав самоорганизующихся команд, которые занимались решением бизнес-задач и разворачивали свои приложения на производственной площадке до 25 раз в день. Он рассчитывает на то, что в будущем его ждет работа над новыми захватывающими программными продуктами бок о бок с другими увлеченными людьми и возможность постоянно совершенствоваться в решении разнообразных задач.
О научном редакторе
Энтони Деньер (Antony Denyer) выступает в роли разработчика, консультанта и коуча и профессионально занимается разработкой программного обеспечения с 2004 года. Он работал над целым рядом проектов, где эффективно применялись идеи и приемы предметно-ориентированного проектирования. Некоторое время назад он стал активно отстаивать использование CQRS и REST в большинстве своих проектов.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 20% по купону — DDD
