image Писать программы легко — во всяком случае, с нуля. Но изменить однажды написанный программный код, который создали другие разработчики или вы сами каких-то шесть лет тому назад, — гораздо сложнее. Программа работает, но вы не знаете точно, как именно. Даже обращение к экспертам в предметной области ничего не дает, поскольку в коде не сохранилось никаких следов привычного для них языка.

Предметно-ориентированное проектирование (Domain-Driven Design, DDD) — это процесс тесной увязки программного кода с реалиями предметной области.Благодаря ему добавление в программный продукт новых возможностей по мере его развития становится таким же простым, как и при создании программы с нуля. Эта книга в полной мере соответствует философии DDD и позволяет разработчикам перейти от философских рассуждений к решению практических задач.

Пространство задачи


Прежде чем приступать к разработке решения, следует понять поставленную задачу. DDD подчеркивает необходимость вникнуть в предметную область бизнес-задачи — разобраться в ее терминологии, выявить глубинные причины, стоящие за потребностью в разработке программного обеспечения, и понять, что является успехом с позиций бизнеса. Жизненно важно, чтобы такое владение темой стало для разработчиков столь же ценным и ценимым качеством, как технические знания и опыт: это дает возможность глубже понять предметную область и помогает разделить большую область на более мелкие части.

На рис. В.1 представлен общий вид пространства задачи (problem space) в DDD, о котором рассказывается в первой части книги.

image


Пространство решений


Составив ясное представление о предметной области, вы сможете с помощью стратегических шаблонов DDD реализовать техническое решение, согласованное с предметной областью. Стратегические шаблоны позволяют оградить основные части системы, крайне важные для успеха продукта, от влияния неспециализированных областей. Благодаря изоляции неотъемлемых компонентов системы их последующие изменения не отразятся рикошетом на остальной системе.

В основе тех ключевых подсистем вашего продукта, которые достаточно сложны или будут часто изменяться, должна лежать модель. Тактические шаблоны DDD вкупе с архитектурой на основе модели (Model-Driven Design) помогут вам создать полезную модель предметной области в коде. Модель — это вместилище всей той прикладной логики, благодаря которой приложение выполняет все бизнес-сценарии использования. Модель отделена от технических сложностей, что оставляет простор для развития и изменения бизнес-правил и регламентов. Модель, согласованная с предметной областью, сделает ваше программное обеспечение легко адаптируемым и понятным для других разработчиков и специалистов со стороны бизнеса.

На рис. В.2 представлен общий вид пространства решений (solution space) DDD, о котором также рассказывается в первой части книги.
image


Структура этой книги


Часть 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
Поделиться с друзьями
-->

Комментарии (8)


  1. ProSerg
    19.07.2017 14:27
    +2

    Скажите, пожалуйста, в электроном формате (pdf, epub) будет ли представлена книга?
    Спасибо!


    1. ph_piter
      19.07.2017 14:28
      +1

      К сожалению, электронных прав нет.


      1. apro
        19.07.2017 17:08
        +1

        Жаль уже лет 5 не покупаю бумажных книг — нет для них места в доме,
        и поиск неудобный.


  1. OlegZH
    19.07.2017 14:39
    +1

    Это теоретическая книга?

    Если да, то она описывает возможный подход, каким ом мог бы быть. Безусловно, это очень важно и нужно знать, как можно действовать, если хочется действовать эффективно.

    Если речь идёт о том, что успешно используется на практике, то в книге явно не хватает обзора реальных примеров. Причём, тут важны не только положительные примеры («вот, посмотрите, как хорошо получается, если делать всё по уму»), но и отрицательные примеры (в том смысле, что если что-то делается не «по уму», то очень важно выявить конкретный источник проблемы). Хотя (кстати!) важны и отрицательные примеры в прямом смысле этого слова, когда показываются ограничения предлагаемого подхода, о которых надо обязательно знать, чтобы не ждать слишком большего и чтобы следить за тем, чтобы применять подход только при условии его применимости (как в физике: «предположим, что имеется идеальный математический маятник с нерастяжимой нитью и пренебрежимо малым сопротивлением воздуха...»).

    Вообще, это должна быть, наверное, настольная книга каждого разработчика (судя по оглавлению). Причём, это должно быть чем-то вроде учебника по специальности «Разработка программного обеспечения». Чтобы из стен учебных заведений выходили грамотные специалисты, владеющие системным мышлением и подходом.

    Глава 10 повествует о том, как убедить других в преимуществах DDD и начать применять принципы и приемы этого подхода в своих проектах. Здесь объясняется, почему попытки создать идеальную модель предметной области не так ценны для создания качественного программного обеспечения, как исследования и эксперименты.
    Ключевой момент книги, да и всей разработки программного обеспечения!

    Попытка создать идеальную модель превращает практика -программиста в созерцателя, но ошибочно трактуемые и ошибочно проводимые эксперименты рискуют привести к не гибким системам. Как соблюсти баланс между теорией и практикой? Постановка этого вопроса, правда, не учитывает следующих обстоятельств: во-первых, кто мешает делать теоретические изыскания параллельно с экспериментами; во-вторых, что мешает различным группам разработчиков объединять результаты своих теоретических изысканий; и, наконец, в-третьих, если, всё-таки, идеальная модель существует и является достижимой, то не означает ли это потенциальную возможность создания универсальной библиотеки компонентов?

    Таким образом, главная проблема любого предметно-ориентированного анализа заключается в том, что этот анализ всё время приходится начинать заново. И каждая компания делает это самостоятельно один на один с клиентами. Опыт этого анализа и результаты этого анализа оказываются недоступными широкой общественности. (Кроме как в виде отдельных статей для специалистов.) А если обобщить накопленный опыт, то, наверное, можно было бы построить некую единую для всех концептуальную модель, и тогда все разработчики будут действовать в едином адресном пространстве и уже к началу разработки будут иметь существенный задел.

    P.S. Вот, по моему совершенно скромному мнению, есть одна существенная проблема: реализация всех элементов системы на одном и том же уровне абстракции. Например, если делается приложение, то пользовательские классы находятся там же, где и базовые классы, реализующие числа, строки, списки, очереди, файлы и и.т.д и т.п. Между тем, кажется очевидным, что Вы должны создать, сначала, некую инфраструктуру, чтобы ввести понятие «программного объекта» (основного объекта, с которым Вы будете дальше работать в приложении), а это значит, что Вы никогда не будете использовать структуры для представления отдельных записей таблиц баз данных, зато Вы всегда будете иметь под руками метаданные, позволяющие Вам задавать локальные проверки обрабатываемых данных и то, что именно должно отображаться в пользовательском интерфейсе.

    Другая сторона вопроса — это то, что можно назвать «безИсходным программированием» (без исходников). Если бы программы позволяли бы создавать свои же собственные исходники, то процесс модернизации программного обеспечения существенным образом упростился бы. Например, было бы достаточно иметь в операционной системе компилятор, конфигуратор, приложение и кодовое представление новых требований (фич), то, «распечатав» программу в конфигураторе и осуществив слияние «распечатки» с новыми требованиями, можно было бы пропустить результат через компилятор и получить новую версию приложения, учитывающую более детальную схему предметной области.

    И, последнее. Важнейший источник проблемы проектирования программных систем заключается в том, что приложения создают сразу на целевом языке программирования. Между тем, начальное (проектное) состояние приложения должно существенно отличаться от конечного продукта. Условно говоря, конечный программный продукт должен получаться в результате «распечатки» из-под проекта той же системы. При этом, вовсе не обязательно, чтобы язык реализации проекта совпадал с языком реализации конечного приложения. Скорее, наоборот, каждый язык программирования должен определяться кругом решаемых задач…

    P.P.S. Что-то я очень много написал! Остановлюсь. А то в ответ на одну книгу придётся написать другую. Хотя, да, было бы крайне любопытно (если будет возможность почитать сам книгу), детально проанализировать её на страницах Хабра. Но что, уж точно, не помешало бы, так это снабдить книгу толстенным томом с описанием конкретных примеров и с указанием как ошибок, так и достижений.


  1. Twindo
    19.07.2017 15:12
    +1

    Будет ли электронная версия книги?


    1. SvSon
      20.07.2017 10:04

      Наверное нет
      https://habrahabr.ru/company/piter/blog/333696/#comment_10319168


  1. OlegZH
    21.07.2017 14:58

    Любопытно было посмотреть на отрывок, предоставленный на сайте издательства. Там представлено начало главы 12 («Интеграция посредством обмена сообщениями»).

    1. Глава начинается с раздела «Загружаемые примеры кода для этой главы», но к этому разделу относится только первый абзац. Затем идёт нормальное введение в главу. Почему так сделано?

    2. Далее, начинается, собственно, описание шины сообщений: «Если в системе имеется единственный централизованный компонент, отвечающий за отправку всех сообщений, вся система может обрушиться, если этот компонент прекратит работу». Наверное, книга очень толстая. 832 страницы! Иногда кажется, что объём можно сократить, делая небольшие введения, чтобы не объяснять в разных местах книги то или иное соображение.

    3. Также имеется ссылка на рисунок: «Шина сообщений обеспечивает коллективную работу всех частей, как показано на рис. 12.1.». Какой смысл в этом рисунке? Между прочим, он занимает место, но совершенно ничего не добавляет к сказанному в тексте, и, уж точно, не показывает, как именно шина сообщений обеспечивает коллективную работу, поскольку на рисунке показаны только сами связи. Картинка имела бы смысл, если бы на ней изображались какие-то важные детали реализации.

    4. Автор(ы) пишут, что «Централизованный компонент, принимающий и рассылающий все сообщения, называют брокером сообщений (message broker), или просто брокером». Интересно, рассказывают ли авторы в своей книге о CORBA? И, если шире ставить вопрос, что они говорят о предшествующих попытках предложить что-то вроде предметно-ориентированного подхода?

    5. Также, имеется любопытное примечание:

    Как упоминалось в предыдущей главе, под компонентами в этой главе понимаются отдельные приложения, которые можно распространять и развертывать независимо друг от друга. Вы также можете встретить такие названия, как «автономные компоненты» (autonomous components), «распределенные компоненты» (distributed components), «компоненты, обменивающиеся сообщениями» (messaging components) и даже «микрослужбы» (micro services). К сожалению, сообщество разработчиков пока не нашло точного, однозначного и непротиворечивого названия.
    От основополагающей книги ожидаешь, что в ней самой предлагается своя чёткая терминология, устраняющая разнобой и позволяющая понять, чем должен быть компонент на самом деле.

    В общем, было бы любопытно как-нибудь прочитать на досуге (которого, увы, пока нет) эту книгу, а потом подумать о том, как её можно было бы написать по другому. и, наверное, гораздо короче. Интересно, что можно написать, например, на двухстах страницах?


  1. nefone
    24.07.2017 12:09

    Заинтересовала книга, сейчас как раз мучаюсь с построением правильных архитектурных решений для своих приложений.