Эванс эрик предметно ориентированное проектирование: Предметно-ориентированное проектирование на самом деле / Хабр

Предметно-ориентированное проектирование на самом деле / Хабр

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

Под катом я хотел бы рассказать о том, что составляет масштаб, почему Эванса нужно дочитать, почему предметно-ориентированному проектированию 100 лет в обед и кое-что от себя.

Четвёртая часть книги Эрика Эванса посвящена стратегическому проектированию. Предметно-ориентированное моделирование как колонны проходят сквозь ваши микросервисы, особенно если они декомпозированы по субдомену. В архитектуре зданий, сооружения не состоят из одной колонны — их строят из множества получая каркас. О том как же получить этот каркас и написана последняя часть Big Blue Book в трёх разделах: взаимодействие между контекстами, дистилляция модели, крупномасштабная структура.

Взаимодействия между контекстами

Описание этих взаимодействий, которые очень хорошо представлены у Эванса и Вернона, это первый шаг к построению ландшафта — осознать с чем именно можно работать, на кого можно положиться.

Назначение карты контекстов — спрогнозировать возможности по развитию ограниченных контекстов. В условиях Enterprise, такая схема позволит правильно подумать над тем, что может бескровно эволюционировать, а где могут возникнуть существенные проблемы. Так, решая проблемы, где-то необходимо прийти к административному ресурсу, где-то чаще повстречаться (может быть провести ряд meet’апов для повышения вовлечённости вышестоящей команда, а иногда пойти по пути отдельного существования.
Если взглянуть на карту взаимодействия между контекстами с точки зрения экономики, то мы строя карту контекстов получаем план производства в организации.

Дистилляция

Дистилляция — деятельность направленная на первоначально получение информации о самых важных частях системы, которая только готовится к проектированию.

Применив дистилляцию, разработчики получают возможность быстрее распознать предмет работы, в котором как раз и появляется добавленная стоимость. Дистиллированное смысловое ядро отражает то, с каким вниманием и важностью необходимо проводить работы над системой. Комбинируя дистилляцию с картой контекста, можно правильно распределить усилия по разработке системы.

Крупномасштабная структура

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

В довершение обзора Стратегического моделирования, я бы хотел отметить, что автор Big Blue Book не просто даёт рекомендации по построению системы, а добавляет к системе измерение — разработчиков которые делают эти системы. И причиной этого он несколько раз указывает необходимость слаженной, совместной работы, упоминает Agile и CI, намекая на то что успех предметно-ориентированного проектирование зависит не только лишь от компетентности, но и горизонтального взаимодействия самоорганизующихся разработчиков. Т.е. работа, падающая сверху в виде проработанных таск через иерархию не будет DDD.

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

Авангардная архитектура

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

Итак, знакомьтесь — конструктивизм в архитектуре:

Самое большое развитие конструктивизм получил в 20е годы, стараниями советских архитекторов. Предвестником этой революционной архитектуры стал известный французский архитектор Ле Корбюзье, провозгласивший свой знаменитый тезис дом - машина для жилья и сформулировавший пять отправных точек архитектуры:

1. Колонна должна стоять свободно в открытом пространстве.
2. Конструктивный каркас здания функционально не зависит от стены и внутренних перегородок.
3. Свободный план не  зависит от  конфигурации наружных стен.
4. Фасад  определяется  внутренней каркасной конструкцией здания.
5. Сад на крыше  раскрывает пространство дома вверх.

Сотни лет архитекторы проектировали коробки, с «правильными» фасадами, а содержание здания планировалось по остаточному принципу. Теперь же всё по-другому — провозглашается единство формы и функции.

Так случилось, что единственным местом, где новый стиль задышал полной грудью, стала молодая страна базирующаяся на новых экономических принципах. Появился запрос, на формирования нового человека, нового уклада жизни. Сама работа архитекторов того времени нам бы показалась очень необычной. Они работали совместно, стараясь поучаствовать во всех проектах, на которые находили время. Они собирались в «группировки», такие как ОСА, АСНОВА, АРУ, ВОПРА. В их работе были признанные авторитеты, но совершенно не было иерархии.

Сама система обучения этих архитекторов в вышей степени интересна, что хорошо можно видеть на примере ВХУТЕМАС. Во-первых, это альтернативное не классическое учебное заведение. Во-вторых, сам учебный процесс был постоен очень необычно — студентам давали возможность с самых необычных сторон подойти к своему делу. В-третьих, структура ВУЗа, преподавания не иерархичная начинающаяся с ректора, а образовалась вокруг авторитета преподавателей. В-четвёртых, в разное время там преподавали такие люди как А. Е. Архипов, А. Д. Древин, В. В. Кандинский, Д. Н. Кардовский, Н. А. Ладовский, В. Ф. Кринский, Л. М. Лисицкий, К. С. Мельников, П. В. Митурич, Н. И. Нисс-Гольдман, А. М. Нюренберг, А. М. Родченко, В. Ф. Степанова, В. Е. Татлин, В. А. Фаворский, П. А. Флоренский, Ф. О. Шехтель, П. И. Келин, А. Ф. Лолейт, И. С. Ефимов, Н. В. Докучаев, Г. О. Чириков и другие. В.В. Кандинский — это авторо той самой Композиции VIII:

Совпадение?

Чтобы перейти ближе к связи с ПО, хотел бы привести конкретный пример, который смог увидеть совершенно случайным образом на экскурсии (рекомендую).

Дом-коммуна на Орджоникидзе

В 1928 молодой архитектор Иван Сергеевич Николаев получил заказ на проектирование студенческого дома-коммунны на 2000 мест от Текстильстроя. Дом на улице Орджоникидзе стал первым домом-коммунной в Москве. Приступая к проектированию, Николаев опросил студентов о, их быте, режиме дня (очень напоминает EventStorming).

Как видно из наброска, Иван Сергеевич изначально планировал это здание в новом стиле. И это не просто авторский замысел — а потребность в новых формах архитектуры, в новом быте людей, в новом человеке.

Что же интересного в этом здании со стороны прогера знакомого с DDD? Начну с одного из фасадов.

Для начала, можно заметить что тут соблюдены все принципы Ле Корбюзье. Здание стоит на колоннах — под ним можно пройти, оставить машину. И это пример продуманного интерфейса и UX, не правда ли. Сами колонны являются основанием для каркаса здания, позволяя проводить свободную планировку. Фасад здесь вторичен и функционален — максимум остекления для освещения. Совсем так же как в разработке ПО, мы проектируем предметную модель, а затем остальные части системы.

Все части здания предельно функциональны — для каждого вида деятельности отдельный корпус или его часть. В одном корпусе студенты просыпаются, в другом принимают душ, идут в столовую, оттуда на занятия, потом кружки и библиотека и снова спать. Что тут необычно — это то, что здание не построено коробкой и разбито на корпусы. Каждая часть здания, отвечающая за определённую деятельность спроектирована отдельно, а всё вместе соединенно в потрясающую композицию. Позволю себе тут метафору с микросервисами, которые составляют ландшафт.

Связь с нашей деятельностью — самая прямая. Николаев подошёл к решению задач с тех же позиций, как когда мы планируем сделать крупную систему с использованием принципов предметно-ориентированного проектирования. Он провёл опрос студентов, предметно спроектировал каждый вид их деятельности, и скомпоновал должным образом. Продуманная история о том, как студенты проживают свою жизнь в таком общежитии — и есть продуманный UX. Сам каркас здания во многом — крупномасштабная структура, которая задавала точки расширения и основной фокус работ. Отсутствие фасада в привычном смысле — вместо этого стены строятся вокруг назначения конкретной части здания. И это полностью соответствует проектированию на основе модели в информационных системах.

Куда делся конструктивизм?

Эти великолепные шедевры авангарда, можно видеть во многих крупнейших городах России и прилежащих стран. Ещё больше можно увидеть его в современных зданиях и даже небоскрёбах. Но в целом конструктивизм существовал в основном в двадцатые годы прошлого столетия. Спрос на данные работы сменился ужесточениями, а в отношении некоторых даже репрессивными мерами.

На съезде архитекторов 1932 года, конструктивизм был признан излишне левым, не соответствующим интересам партии и нового времени — мещанство победило. Если не касаться совсем уж политики, то важно сказать что случилось после съезда. Архитектурные группировки были распущены, а проектная деятельность сосредоточилась в руках одного института. Т.е. из горизонтальной структуры образовалась иерархия строго подчинения. Так началась история ампира и хрущёвок, но это уже не то что нам интересно.

Для чего можно использовать Domain Driven Design?

• Если проработать техническую часть (контексты, агрегаты и т.п.), можно сделать несколько хороших модулей, которые будут вполне адаптивны к изменениям.
• Если проработать ряд модулей, то можно заняться стратегическим проектированием (кратко описано выше).
• Если есть стратегический проект, можно сделать очень достойную микросервисную архитектуру.
• Микросервисная архитектура сделанная по DDD согласно закону Конвея будет повторять структуру организации.
• Модель организации может быть использована для ML-механизмов, контроля качества, автоматизации.
• Организация
  • станет более конкурентноспособной;
  • простой труд станет менее востребован, высококвалифицированный более востребованный.

Если дойти до конца, то возможно разработчики будут уже не просто сервисом к бизнесу, а будут менять его. И в тот момент, когда количество таких локальных изменений станет достаточно большим, изменится и сама ткань общества. Во многом, это и есть продолжение того, что сейчас называют четвёртой промышленной революцией по Швабу, ведь в результате работы мы получаем виртуальную модель производства.

Я привёл в пример Эванса и авангардистов, чтобы показать, что сложности с DDD и его смысл, не в техническом аспекте, а в экономическом и несколько политическом. Успех больших проектов во многом зависит от того, насколько команда(ы) разобщены и подчиненны иерархии. Архитектор в одно лицо не сможет сделать огромный проект и следить за корректностью его реализации. А армия аналитиков и продактов даже не сможет задать нужные вопросы, ведь они решают свою задачу показателей, не владеют стратегическим проектированием, часто лишены технической экспертизы. В подтверждение может выступать один из принципов Agile — Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

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

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

Как Ле Корбюзье дал архитекторам общие принципы архитектуры зданий, с помощью которых те меняли быт людей, так и Эрик Эванс описал DDD и принципы борьбы со сложностью предметной области, которые в полной своей совокупности могут помогать бизнесу. Самое главное в этом подходе — это работать над командой профессионалов, меньше думать о том, чему могут научить вас, а чему вы можете научится вместе с командой!

САМООРГАНИЗАЦИЯ ИЛИ ВАРВАРСТВО

P.S. Искренне советую посетить экскурсии по конструктивизму. Рассказы об этих зданиях, как будто об архитектуре микросервисов у себя! Особенно если вы дочитали Эванса…

паттерны, принципы и методы» / Блог компании Издательский дом «Питер» / Хабр

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

Предметно-ориентированное проектирование (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

Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем | Эванс, Эрик

Классическая книга Э. Эванса освещает наиболее общий, стратегический круг вопросов, связанных с объектно-ориентированной разработкой программного обеспечения. Это переработка и структуризация знаний о предметных областях, применение типовых архитектурных шаблонов, построение и анализ моделей предметных областей, проектирование программных объектов с точки зрения качества их взаимодействия и передачи логической структуры знаний, организация программ на основе крупномасштабных структур, выработка общего языка и стратегии коммуникации в группе. Подход автора строится на динамичном рефакторинге модели и постоянной дистилляции знаний. Это позволяет достигнуть высокой степени гармонии между логикой предметной области и кодом программы, а также достаточной гибкости программной архитектуры для целей удобной доработки и интеграции программного обеспечения. Книга насыщена практическими примерами из реальных проектов.
Мировое сообщество программистов признает, что моделирование предметных областей — ключевой раздел проектирования программного обеспечения. В моделях предметных областей разработчики выражают сложные функции своих программ, реализуя их затем в таком виде, который отвечает реальным потребностям пользователей. Но несмотря на очевидную важность предмета, существует очень мало пособий по эффективному внедрению моделирования предметных областей в практику разработки программ.
Книга Эрика Эванса заполняет этот пробел. Она посвящена не отдельным технологиям, а систематическому предметно-ориентированному подходу. В ней представлен широкий набор приемов и методик, основанных на практическом опыте, и фундаментальных принципов, помогающих в реализации программных проектов из сложных предметных областей. Органично переплетая практику проектирования и реализации программ, эта книга содержит множество фактических примеров, иллюстрирующих применение общих стратегических принципов в реальных программных проектах.
Из книги читатель узнает, как с помощью модели предметной области придать разработке сложной системы нужную направленность и динамику. Выделены основные приемы и образцы-шаблоны, образующие общий язык группы разработчиков. Особо подчеркивается необходимость рефакторинга не только кода, но и модели в его основе, что в сочетании с итерационной agile-методикой приводит к углублению знаний о предметной области и повышению качества взаимодействия между специалистами и программистами. Подход книги строится именно на этом фундаменте, предлагая модели и архитектуры для систем и организаций любой сложности.

Файл содержит OCR и ссылочное оглавление.

Содержание

Введение

Модель предметной области в работе

Роль и выбор модели

Алгоритмическая часть программы

• Переработка знаний

Составляющие эффективного моделирования

Переработка знаний

Непрерывное обучение

Информоемкая архитектура

Извлечение скрытого понятия

Углубленные модели

• Коммуникация и язык

Единый язык

Моделирование вслух

Одна команда — один язык

Документация, диаграммы, схемы

Письменная проектная документация

Выполняемый код решает все

Пояснительные модели

• Связь между моделью и реализацией

Проектирование по модели

Парадигмы моделирования и средства программирования

Анатомия модели: зачем модель нужна пользователю

Моделировщики-практики

Структурные элементы предметно-ориентированного проектирования

• Изоляция предметной области

Многоуровневая архитектура

Связь между уровнями

Архитектурные среды

Уровень предметной области — вместилище модели

Антишаблон интеллектуального интерфейса пользователя

Другие виды изоляции

• Модель, выраженная в программе

Ассоциации

Сущности (указуемые объекты)

Моделирование сущностей

Проектирование операций идентификации

Объекты-значения

Проектирование объектов-значений

Проектирование ассоциаций с помощью ОБЪЕКТОВ-ЗНАЧЕНИЙ

Службы

Службы и изоляция уровня предметной области

Степень модульности

Доступ к службам

Модули (пакеты)

Гибкая модульность

Ловушки инфраструктуры

Парадигмы моделирования

Причины доминирования объектной парадигмы

He-объекты в объектном мире

Проектирование по модели в условиях смешения парадигм

• Цикл существования объектов модели

Агрегаты

Фабрики

Выбор фабрик и их местонахождения

Когда достаточно конструктора

Проектирование интерфейса

Где реализовать логику инвариантов?

Отличия между фабриками сущностей и фабриками объектов-значений

Восстановление хранимых объектов

Хранилища

Запросы к хранилищам

Клиентам безразлична реализация хранилищ, а разработчикам — — нет

Реализация хранилища

Работа в рамках архитектурной среды

Связь с фабриками

Проектирование объектов для реляционной базы данных

• Работа с языком: расширенный пример

Введение в систему управления доставкой

Изоляция предметной области: добавление прикладных операций

Отделение сущностей от значений

Роль и другие атрибуты

Проектирование ассоциаций в модели

Границы агрегатов

Выбор хранилищ

Проход по сценариям

Пример рабочей функции: изменение места назначения груза

Пример рабочей функции: повторение заказов

Создание объектов

Фабрики и конструкторы для объекта Груз

Добавление объекта Манипул

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 для широкой публики была так называемая “Большая синяя книга” (мем. BBB: Big Blue Book): Domain-Driven Design: Tackling Complexity in the Heart of Software byEric Evans (на русский язык пока не переведена).

Книга довольна подробно рассказывает о том, что из себя представляет DDD, и все связанные аспекты, такие как: язык предметной области, шаблоны, практики проектирования, рефакторинг, моделирование, как сделать разработку гибкой и многое другое. Но даже если вы ознакомитесь со всеми вопросами, поднятыми в книге (что является не совсем простым занятием), вы обратите внимание, что вопросы рассматриваются только с теоретической точки зрения, оставляя весь простор для практики (книга не привязана к конкретной платформе разработки). Для большинства из нас чтение чистой теории, без подкрепления практическими примерами не нравится, в связи с этим можно обратить своё внимание на сокращенную (и свободную для доступа) версию этой книги, подготовленную порталом InfoQ: Domain Driven Design Quickly.

Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:

1) DDD: putting the model to work

2) Eric Evans on DDD: Strategic Design

На портале InfoQ можно найти множество других презентаций, статей и интервью, посвященных DDD.

Итак, с теоретической частью мы разобрались, где же можно найти примеры практического применения DDD? Отличной книгой для этого является .NET Domain-Driven Design with C#, Problem – Design – Solution написанная Tim McCarthy. 

В этой книге вы наёдете практические примеры:

1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода

2) Как организовывать архитектурные слои в своих решениях

3) Как применять шаблоны и практики DDD

4) Как построить небольшой каркас для DDD

5) Как изолировать домен предметной области от модели

6) Современные паттерны представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight) в практики.

Эта книга – отличный практикум по DDD, содержащий очень широкий пласт идей. Начинается книга с разработки требований, а заканчивается реализацией промышленного приложения, исходные коды которого доступны на Codeplex.

Вся концепция книги построена на 3 книгах-столпах DDD:

1. PoEAA Мартина Фаулера
2. DDD Эрика Ивенса
3. Applying Domain — Driven Design and Patterns by Jimmy Nilsson’s (“Применение шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET” Джимми Нильссона )

В этой книге поверхностно рассмотрены все вопросы, техники и паттерны, применяемые в DDD, все примеры сопровождаются кодом, что упрощает понимание. Книга превосходная, однако русский перевод подкачал, поэтому, рекомендую прочитать оригинал.

Однако DDD – это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо учитывать, если вы решили следовать DDD, таких как: фокусирование на высокий приоритет отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д…это является  основной причиной ознакомиться с книгой Эрика Ивенса, так как она даст вам более объемное и глубокое понимание философии DDD.

DDD не привязанны к конкретной технологии, однако соблюдать DDD будет не так просто, без наличия хороших средств и практик в вашем арсенале, таких как: TDD-фреймворк, ORM, возможность реализации независимости сохраняемости (Persistence Ignorance), IoC-контейнер (Inversion of Control), и возможностей AOP (Аспектно-Ориентированного Программирования), конечно не значит, что все эти инструменты нам понадобятся, однако они приблизят нас к реализации DDD на практике. Практичная ценность этих средств в том, что они позволять изолировать модель предметной области, что является ключевой целью DDD. Книга Джимми Нильссона может познакомить вас с возможностями и видами данных инструментов. Джимми так же показывает как использовать шаблоны реализации корпоративных приложений, и строить, благодаря им, цельное решение, основанное на современных инструментах и практиках.

Некоторые реализации шаблонов DDD на Ruby On Rails:

Some DDD (Domain Driven Design) Concepts implemented in Rails

4. Актуальные вопросы DDD

C DDD так же тесно связана такая тема, как DDDD: Distributed Domain Driven Design (Распределенный DDD). DDDD – это DDD в распределенных сценариях. В настоящее время существует не так много ресурсов, посвященных DDDD, в нескольких словах о DDDD: покрывает проблему реализации сообщений и DDD, разделение команд и запросов (Command Query Separation (CQS)) помогает реализовать данный подход. Грег Янг (Greg Young) сообщил, что готовит книгу, посвященную DDDD.

SOA и DDD – это ещё одна объемная тема, часто обсуждаемая Udi Dahan

5. DDD шаблоны, концепции и понятия

В промышленных приложениях DDD использует ряд шаблонов, часть которых описана в книге Эрика Ивенса, но, это не отменяет применение объектно-ориентированного подхода, включающего GoF-шаблоны,  шаблоны Мартина Фаулера, описанные в его PoEAA, Шаблоны интеграции корпоративных приложений и т.д.…

Вот некоторые из них:

6. Примеры приложений

Найти хорошие примеры реализации 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 на конкретной платформе, что позволит без труда осуществить тоже самое на любой другой платформе.
• Помочь в выборе реализуемых практик. Различные подходы позволят сообществу обсудить их и выбрать соответствующий для конкретной реализации.

здесь более подробная информация.

7. Ресурсы по Domain Driven Design

Официальный сайт — http://domaindrivendesign.org/

Группа обсуждений — http://tech.groups.yahoo.com/group/domaindrivendesign/ это взрослая группа, очень хороший источник идей, место для обсуждений всех видов проблем в области DDD. В ней на ваши вопросы могут ответить опытные в DDD люди, даже Эрик Ивенс :-).

Блог Jimmy Bogard’а — http://www.lostechies.com/blogs/jimmy_bogard/default.aspx

Блог Colin Jack’а — http://colinjack.blogspot.com/

Блог Greg Young’а — http://codebetter.com/blogs/gregyoung/default.aspx

Блог Casey Charlton’а — http://devlicio.us/blogs/casey/

Блог Udi Dahan’а — http://www.udidahan.com/

Введение в Domain-Driven Design — http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

8. Заключение

Если вы заинтересованы в расширении ваших “объектно-ориентированных горизонтов” в сложных корпоративных системах и изучении новых способов разработки и проектирования, то DDD – именно то что нужно.

http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx

Иллюстрация 1 из 1 для Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем — Эрик Эванс | Лабиринт

Классическая книга Э. Эванса освещает наиболее общий, стратегический круг вопросов, связанных с объектно-ориентированной разработкой программного обеспечения. Это переработка и структуризация знаний о предметных областях, применение типовых архитектурных шаблонов, построение и анализ моделей предметных областей, проектирование программных объектов с точки зрения качества их взаимодействия и передачи логической структуры знаний, организация программ на основе крупномасштабных структур, выработка общего языка и стратегии коммуникации в группе. Подход автора строится на динамичном рефакторинге модели и постоянной дистилляции знаний. Это позволяет достигнуть высокой степени гармонии между логикой предметной области и кодом программы, а также достаточной гибкости программной архитектуры для целей удобной доработки и интеграции программного обеспечения. Книга насыщена практическими примерами из реальных проектов.
Мировое сообщество программистов признает, что моделирование предметных областей — ключевой раздел проектирования программного обеспечения. В моделях предметных областей разработчики выражают сложные функции своих программ, реализуя их затем в таком виде, который отвечает реальным потребностям пользователей. Но несмотря на очевидную важность предмета, существует очень мало пособий по эффективному внедрению моделирования предметных областей в практику разработки программ.
Книга Эрика Эванса заполняет этот пробел.
Она посвящена не отдельным технологиям, а систематическому предметно-ориентированному подходу. В ней представлен широкий набор приемов и методик, основанных на практическом опыте, и фундаментальных принципов, помогающих в реализации программных проектов из сложных предметных областей. Органично переплетая практику проектирования и реализации программ, эта книга содержит множество фактических примеров, иллюстрирующих применение общих стратегических принципов в реальных программных проектах.
Из книги читатель узнает, как с помощью модели предметной области придать разработке сложной системы нужную направленность и динамику. Выделены основные приемы и образцы-шаблоны, образующие общий язык группы разработчиков. Особо подчеркивается необходимость рефакторинга не только кода, но и модели в его основе, что в сочетании с итерационной agile-методикой приводит к углублению знаний о предметной области и повышению качества взаимодействия между специалистами и программистами. Подход книги строится именно на этом фундаменте, предлагая модели и архитектуры для систем и организаций любой сложности.
В частности, в книге рассматриваются следующие темы:
Единый язык общения для всей группы разработчиков.
Глубокая связь между моделью и программной реализацией.
Выделение ключевых черт модели.
Управление циклом существования объектов.
Написание легко интегрируемого кода предметной области.
Как сделать сложный код очевидным и предсказуемым в поведении.
Формулировка введения в предметную область.
Дистилляция ядра предметной области.
Поиск неявных понятий, скрытых в модели.
Применение аналитических шаблонов.
Архитектурные шаблоны в моделях.
Поддержание целостности больших систем.
Сосуществование нескольких моделей в одном проекте.
Организация систем в соответствии с крупномасштабными структурами.
Качественные скачки в моделях.
Имея под рукой эту книгу, разработчики объектно-ориентированных программ, системные аналитики и архитекторы будут всегда располагать набором рекомендаций по организации своего труда, созданию сложных и полезных моделей предметных областей, превращению их в высококачественные, долгоживущие программные продукты.
Книга предназначена для повышения квалификации программистов, работающих, в частности, по методикам экстремального программирования и agile-разработки. Может быть полезна студентам соответствующих специальностей.
Об авторе
Эрик Эванс, является основателем Domain Language — консультативной группы, которая помогает различным фирмам строить и развивать программные системы, тесно связанные с их профессиональной деятельностью. Автор работал в качестве архитектора и программиста над большими объектно-ориентированными системами в ряде сложных коммерческих и технических предметных областей, начиная с 1980-х годов. Он также занимается повышением квалификации групп разработчиков в области экстремального программирования.
«Эта книга должна стоять на полке у всякого мыслящего программиста.»
— Кент Бек (Kent Beck)
«Эрику удалось ухватить суть того, что опытные проектировщики программных объектов всегда знали, но проваливали все попытки донести это знание до своих коллег в смежных областях. Мы охотно делимся отдельными секретами… но никогда не заботились об организации и систематизации принципов построения логической структуры предметной области. Вот почему эта книга так важна.»
— Кайл Браун (Kyle Brown), автор книги «Enterprise Java Programming with IBM WebSphere»

Предметно-ориентированное проектирование (6 книг) » LITMY.RU

Предметно-ориентированное проектирование (6 книг)

Автор: Разные
Название: Предметно-ориентированное проектирование (6 книг)
Издательство: Альфа-книга, Вильямс, Питер,
Год: 2008-2017
Формат: djvu, pdf
Размер: 268.0 MB
Страниц: 3238
Язык: русский
Качество: хорошее

Писать программы легко — во всяком случае с нуля. Но изменить однажды написанный программный код, который создали другие разработчики или вы сами каких-то шесть лет тому назад, — гораздо сложнее. Программа работает, но вы не знаете точно, как именно. Даже обращение к экспертам в предметной области ничего не дает, поскольку в коде не сохранилось никаких следов привычного для них языка.
Предметно-ориентированное проектирование (Domain-Driven Design, DDD) — это процесс тесной увязки программного кода с реалиями предметной области. Благодаря ему добавление в программный продукт новых возможностей по мере его развития становится таким же простым, как и при создании программы с нуля.
Мировое сообщество программистов признает, что моделирование предметных областей — ключевой раздел проектирования программного обеспечения. Но несмотря на очевидную важность предмета, существует очень мало пособий по эффективному внедрению моделирования предметных областей в практику разработки программ. Данная подборка книг освещает принципы, методы, приемы и опыт применения предметно-ориентированного проектирования при разработке программного обеспечения.
Книга Эванса Э. освещает наиболее общий, стратегический круг вопросов, связанных с применением DDD при разработке программного обеспечения. Это переработка и структуризация знаний о предметных областях, применение типовых архитектурных шаблонов, построение и анализ моделей предметных областей, проектирование программных объектов с точки зрения качества их взаимодействия и передачи логической структуры знаний, организация программ на основе крупномасштабных структур, выработка общего языка и стратегии коммуникации в группе. Подход автора строится на динамичном рефакторинге модели и постоянной дистилляции знаний. Это позволяет достигнуть высокой степени гармонии между логикой предметной области и кодом программы, а также достаточной гибкости программной архитектуры для целей удобной доработки и интеграции программного обеспечения. Книга насыщена практическими примерами из реальных проектов.
Создание моделей программного обеспечения с помощью предметно-ориентированного проектирования (DDD) принесло много впечатляющих результатов не только в теории, но и на практике. Именно поэтому разработчики во всем мире с энтузиазмом приступили к адаптации DDD. Книга Вернона В. «Предметно-ориентированное проектирование. Самое основное» представляет собой краткий справочник по основам DDD. В ней вы найдете ответы на вопросы: «Что собой представляет DDD, какие проблемы он решает, как работает и как быстро приносит результаты?»
Книга Вернона В. «Реализация методов предметно-ориентированного проектирования» имеет замечательную особенность: она посвящена сложной и содержательной теме и раскрывает ее четко, с нюансами, весело и изящно. Книга написана в увлекательном и дружелюбном стиле. Автор выступает в роли доверительного советника, дающего полезные советы по реализации самых важных аспектов. К тому времени, когда вы закончите читать книгу, вы будете в состоянии применять все важные понятия в области DDD и делать многое другое.
Книга Миллетта С. и Тьюна Н. в полной мере соответствует философии DDD и позволяет разработчикам перейти от философских рассуждений к решению практических задач. Она делится на четыре части. Часть I посвящена философии, принципам и приемам предметно-ориентированного проектирования. В части II подробно обсуждаются стратегические шаблоны интеграции ограниченных контекстов. Часть III охватывает тактические шаблоны создания эффективных моделей предметной области. Часть IV в деталях описывает шаблоны проектирования, которые позволяют извлекать пользу из модели предметной области и создавать эффективные приложения.
Книга Нильссона Дж. посвящена разработке корпоративных программных приложений в среде .NET с применением шаблонов проектирования. В ней описаны: проблемно-ориентированные методы проектирования (DDD), разработка посредством тестирования (TDD, или Test-Driven Development), объектно-реляционное преобразование, т.е. методы, которые многие относят к ключевым технологиям разработки программного обеспечения. По мере развития и усложнения технологии все большее значение приобретают вопросы правильного применения методов проектирования. Ценность этой книги в том и состоит, что она помогает разобраться в этих вопросах.
Автор книги «Шаблоны корпоративных приложений» Фаулер М., известный специалист в области объектно-ориентированного программирования, заметил, что с развитием технологий базовые принципы проектирования и решения общих проблем остаются неизменными, и выделил более 40 наиболее употребительных подходов, оформив их в виде типовых решений. Результат перед вами — незаменимое руководство по архитектуре программных систем для любой корпоративной платформы. Это своеобразное учебное пособие поможет вам не только усвоить информацию, но и передать полученные знания окружающим значительно быстрее и эффективнее, чем это удавалось автору.

Список книг.
1. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем, Эванс Э., Вильямс, 2011, 448 с.;
2. Предметно-ориентированное проектирование. Самое основное, Вернон Вон, Альфа-книга, 2017, 157 с.;
3. Реализация методов предметно-ориентированного проектирования, Вернон Вон, Вильямс, 2016, 690с.;
4. Предметно-ориентированное проектирование: паттерны, принципы и методы, Миллетт Скотт, Тьюн Ник, Питер, 2017, 835 с.
5. Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET, Нильссон Джимми, Вильямс, 2008, 560 с.;
6. Шаблоны корпоративных приложений, Фаулер Мартин, Вильямс, 2016, 548 с.

Скачать с облака

НЕ РАБОТАЕТTURBOBIT.NET? ЕСТЬ РЕШЕНИЕ, ЖМИ СЮДА!

Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.

Использование микрослужб с шаблонами DDD и CQRS для решения сложных бизнес-задач

• 
  10/08/2018
• Чтение занимает 2 мин
• 
  

В этой статье

Разработка модели предметной области для каждой микрослужбы или ограниченного контекста, который отражает понимание предметной области бизнеса.Design a domain model for each microservice or Bounded Context that reflects understanding of the business domain.

Этот раздел посвящен более сложным микрослужбам, которые реализуются для комплексных подсистем, и микрослужбам, создаваемым на основе знаний экспертов в определенной области с учетом постоянно меняющихся бизнес-правил.This section focuses on more advanced microservices that you implement when you need to tackle complex subsystems, or microservices derived from the knowledge of domain experts with ever-changing business rules. Шаблоны архитектуры, используемые в этом разделе, основаны на принципах проблемно-ориентированного проектирования (DDD) и разделения команд и запросов (CQRS), как показано на рис. 7-1.The architecture patterns used in this section are based on domain-driven design (DDD) and Command and Query Responsibility Segregation (CQRS) approaches, as illustrated in Figure 7-1.

Внешняя архитектура: шаблоны микрослужб, шлюзы API, устойчивый обмен данными, публикации и подписки и т.д. Внутривенная архитектура: управление данными, CRUD, шаблоны DDD, внедрение зависимостей, несколько библиотек и т.д.Difference between external architecture: microservice patterns, API gateways, resilient communications, pub/sub, etc., and internal architecture: data driven/CRUD, DDD patterns, dependency injection, multiple libraries, etc.

Рис. 7-1.Figure 7-1. Архитектура внешних микрослужб и внутренние шаблоны архитектуры для каждой микрослужбыExternal microservice architecture versus internal architecture patterns for each microservice

Но большинство методов, применяемых для микрослужб на основе данных, таких как способы реализации службы веб-API ASP.NET Core или предоставления метаданных Swagger с помощью Swashbuckle или NSwag, также применимы и к более сложным микрослужбам, реализуемым с помощью внутренних шаблонов DDD.However, most of the techniques for data driven microservices, such as how to implement an ASP.NET Core Web API service or how to expose Swagger metadata with Swashbuckle or NSwag, are also applicable to the more advanced microservices implemented internally with DDD patterns. Этот раздел дополняет предыдущие, так как большинство описанных ранее методов применимы и в этом случае, а также к любой из микрослужб.This section is an extension of the previous sections, because most of the practices explained earlier also apply here or for any kind of microservice.

В этом разделе сначала приводятся сведения об упрощенных шаблонах CQRS, используемых в образце приложения eShopOnContainers.This section first provides details on the simplified CQRS patterns used in the eShopOnContainers reference application. Далее вы получите представление о методах DDD, позволяющих найти общие шаблоны, которые можно повторно использовать в приложениях.Later, you will get an overview of the DDD techniques that enable you to find common patterns that you can reuse in your applications.

DDD — это обширная тема, по которой доступно множество учебных ресурсов.DDD is a large topic with a rich set of resources for learning. Вы можете начать знакомство с ней с книги Domain-Driven Design (Проблемно-ориентированное проектирование) Эрика Эванса (Eric Evans) и дополнительных материалов от Вона Вернона (Vaughn Vernon), Джимми Нилссона (Jimmy Nilsson), Грега Янга (Greg Young), Уди Дахана (Udi Dahan), Джимми Богарда (Jimmy Bogard) и многих других экспертов по DDD и CQRS.You can start with books like Domain-Driven Design by Eric Evans and additional materials from Vaughn Vernon, Jimmy Nilsson, Greg Young, Udi Dahan, Jimmy Bogard, and many other DDD/CQRS experts. Но учиться применять приемы DDD следует в первую очередь в процессе общения, проведения телеконференций и сеансов моделирования предметных областей с экспертами.But most of all you need to try to learn how to apply DDD techniques from the conversations, whiteboarding, and domain modeling sessions with the experts in your concrete business domain.

Дополнительные ресурсыAdditional resources

DDD (проблемно-ориентированное проектирование)DDD (Domain-Driven Design)

Книги по DDDDDD books

Обучение по DDDDDD training

• Джули Лерман (Julie Lerman) и Стив Смит (Steve Smith). Основы предметно-ориентированного проектирования Julie Lerman and Steve Smith. Domain-Driven Design Fundamentals
  https://bit.ly/PS-DDD

Eric Evans Domain Driven Design PDF

Эрик Эванс-домен-управляемый-дизайн-pdf …

Эрик Эванс Дизайн на основе предметной области pdf Эрик Эванс Дизайн на основе предметной области pdf

СКАЧАТЬ! ПРЯМОЕ СКАЧИВАНИЕ!

Эрик Эванс, проектирование на основе предметной области, pdf Устранение сложности Сложность в основе программного обеспечения. Эрик Эванс ericdomainlanguage.com. ericdomainlanguage.com. бесплатный редактор pdf Final Manuscript, Manuscript, 15 апреля 2003 г. НА МОДЕЛИ.

ecosimp ec osimpro ro pdf pdftext «> eric xt»> eric evans evans проектирование, управляемое доменами, pdf DESIGN Экспресс-модель с изолированным доменом с помощью инкапсуляции с помощью.II: Строительные блоки модельно-ориентированного дизайна. Domain Driven Design — это видение и подход к проектированию. резюмируйте суть того, что такое DDD, опираясь в основном на книгу Эрика Эванса. Этот доклад представляет собой анонимизированный анонимный, обработанный, очищенный от zed edward tufte tufte отчет об опыте загрузки, основанный на реальном проекте клиента Domain Language. В нем рассказывается история появления. Доменно-ориентированный дизайн. Доменно-ориентированный дизайн: преодоление сложности в основе программного обеспечения Эрик Эванс на Amazon.com. БЕСПЛАТНАЯ доставка соответствующих предложений. Описывает способы. Быстро озаглавить предметно-ориентированный дизайн Авторы Абель Аврам, Флойд Маринеску.

domain Dri Drive Ven n Design Эрик Эванс и электронная книга eboo k pdf pdf 2007 Мягкая обложка: 104 страницы Электронная книга PDF 106 страниц, 1. Также включено интервью с Эриком Эвансом о Domain Driven Design сегодня. Вдохновлено основополагающими работами Эрика Evans Domain-Driven Domain-Driven Design и Greg Young Events наряду с новаторской работой таких мастеров программного обеспечения.Доменно-ориентированный дизайн: преодоление сложности в самой основе программного обеспечения. Этот текст посвящен анализу анализа и проектированию программного обеспечения, на которое полагается. Альберто Берто Брандолини Брандолини, инструктор DDD, инструктор, сертифицированный под редакцией Эрика Эванса и. Внедрение доменного дизайна делает замечательную вещь: он. В его содержание входят: о доменно-ориентированном дизайне, представлении модели, универсальном языке, стратегическом.

дизайн, управляемый доменами, книга Эрика Эванса скачать pdf Методы и шаблоны подробно описаны в книге Эрика Эванса Дизайн, управляемый доменами: преодоление сложности в.Эванс Эрик Доменно-ориентированный дизайн: преодоление сложности в основе программного обеспечения PDF.

domain-dr domain -driven design er e ric evans e vans book boo k pdf Предметно-ориентированное проектирование DDD: структуризация сложных программных систем. Издатель.EricEvansDDD Джимми, основанный на применении предметно-ориентированного дизайна и шаблонов. Дизайн, управляемый предметной областью: преодоление сложности в основе программного обеспечения Эрика Эванса, Эрик Эванс. Дизайн Vite fait от Абеля Аврама Флойда Маринеску Редакция от: Dan ec harris logo pdf Bergh Johnsson.1 DDD: запуск модели в работу 2 Эрик Эванс о DDD: стратегический дизайн На портале InfoQ можно найти множество других презентаций. DDD — это подход к разработке программного обеспечения для сложных нужд. Этот термин был введен Эриком Эвансом в его книге с тем же названием. В этой диссертации используются принципы предметно-ориентированного проектирования. Отрывок из интервью с Эриком Эвансом, автором книги Домен. Эрик Эванс написал фантастическую книгу о том, как можно привести дизайн своего программного обеспечения в соответствие с вашей ментальной моделью предметной области.Домен-ориентированный дизайн удовлетворяет эту потребность. Это не книга о конкретных технологиях. Он предлагает читателям систематический подход к предметно-ориентированному дизайну, представленный в презентации. г. Дизайн, управляемый доменом домена, дизайн Эрик Эрик Эванс, Эванс, 2004: определить область Domai Domain, в которой применяется программное обеспечение, чтобы создать абстрактное описание ситуации в модели Model Model. II: Строительные блоки модельно-ориентированного дизайна. Доменно-ориентированный дизайн: преодоление сложности в самом сердце программного обеспечения Эрик Эванс на Amazon.com. Описывает способы. 19 марта 2013 г. В нем рассказывается история появления. Содержание включает: О доменно-ориентированном дизайне, представлении модели, универсальном языке, стратегическом. Методы и шаблоны подробно описаны в книге Эрика Эванса Domain Driven Design: Tackling Complexity in the. Альберто Брандолини, инструктор DDD, ed marlo riffle shuffle systems pdf Сертифицировано Эриком Эвансом и. Внедрение доменно-ориентированного дизайна делает замечательную вещь: it.Title Domain-Driven Design Quickly Авторы Абель Аврам, Флойд Маринеску.2007 г. Мягкая обложка: 104 страницы, электронная книга, PDF, 106 страниц, стр. 1. Также включено интервью с Эриком Эриком Эвансом Эвансом о Domai Domain n Driven Driven Desi Design gn сегодня. сегодня. Вдохновленный основополагающими работами Эрика Эванса Domain-Driven Design и Грега Янга. EricEvansDDD Applying-Domain-Driven-Design-and-Patterns-by-Jimmy. Философия «Domai Domain-Driven Ven Desi Design» объясняется на практическом уровне.М практическая. 29 мая 2009г. 2009г.

СКАЧАТЬ!

Нам доверяют более 1 миллиона участников

Попробуйте Scribd БЕСПЛАТНО в течение 30 дней, чтобы получить доступ к более чем 125 миллионам наименований без рекламы и перерывов! Начать бесплатную пробную версию Отменить в любое время.

Нам доверяют более 1 миллиона участников

Попробуйте Scribd БЕСПЛАТНО в течение 30 дней, чтобы получить доступ к более чем 125 миллионам наименований без рекламы и перерывов! Начать бесплатную пробную версию Отменить в любое время.

ПРЯМО СКАЧАТЬ СКАЧАТЬ! D!

.

Domain Driven Design) / Хабр

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих часто встречающихся за семью печатями, а так же приводимых рядов ресурсов, с довольно неплохо было бы познакомиться при желании продолжить развитие проектирования на основе предметной области (DDD: Domain Driven Design).

2. Так почему же DDD?

Есть несколько шаблонов реализации предметной области (Domain Logic) или бизнес-логики (Business Logic):

1) Table Module — представляет собой объект, в единственном экземпляре, обрабатывающий бизнес-логику для всех записей в таблице базы данных, либо представления.

2) Скрипт транзакции — организует взаимодействие с бизнес-логикой посредников, принимающих запросов с уровня представления.

3) Модель предметной области — непосредственно, объектная модель предметной области, включающая в себя как поведение, так и данные.

Эти шаблоны развития более подробно Мартином Фаулером, в его книге «Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений » (Шаблоны архитектуры корпоративных приложений (P of EAA)) .В данной книге он показывает, что первые два шаблона более привлекательны в начале работы с предметной областью, однако так же обращает внимание, что при наращивании сложности логики предметной области стоит уделять внимание сопровождению инфраструктуры, используя первые два подхода, это время можно уменьшить, если Обратиться в своём решении к третьему из вышеперечисленных шаблонов, так называемой «Модели предметной области».

На основе этого сделаем небольшой вывод о том, что данный шаблон («Модель предметной области») всего подойдёт, к примеру, для такой непростой области, как финансовый рынок.Большинство возможных решений для различных нужд бизнеса, следовательно, какие-то абстрактные, обобщенные находят свое место на рынке (с довольно таки высокой конкуренцией) всё реже и реже. К чему я пишу про всё это? Потому что DDD — это не только качественное проектирование. разрабатывать уродливую, сложную для понимания, в изменение или исправление способно обрушить на вас лавину всё новых и новых дефектов.

DDD ни в коем случае не отрицает наследия практик разработки, таких как:

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

3. С чего можно начать?

Если мой «нудный PR» проектирование на основе предметной области (DDD) вас до сих пор не утомил, то думаю нам стоит продолжить, если же иначе, то посмотрите хотя бы ссылки на материалы.

Первой книг пролившей свет на DDD для широкой публики была так называемая «Большая синяя книга» (мем. BBB: Big Blue Book): Доменно-ориентированный дизайн: устранение сложности в самой основе программного обеспечения by Eric Evans (на русский язык пока не переведена).

Книга довольна подробно рассказывает о том, что из себя представляет DDD, и все связанные аспекты, такие как: язык предметной области, шаблоны, практики проектирования, рефакторинг, моделирование, как сделать модель гибкой и многое другое.Обратите внимание, что вопросы только с теоретической точки зрения, оставляя весь простор для практики (книга не привязана к индивидуальной платформе разработки). Для большинства из чтения нас чистой теории, без подкрепления практическими примерами, с этим можно обратить свое внимание на сокращенную (и свободную для доступа) версию этой книги, подготовленную порталом InfoQ: Дизайн, управляемый доменом, быстро .

Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:

1) DDD: запуск модели в работу

2) Эрик Эванс на DDD: стратегический дизайн

На портале InfoQ можно найти множество других презентаций, статей и интервью, посвященных DDD.

Итак, с теоретической частью мы разобрались, где же можно найти примеров практического применения DDD? Отличной книг для этого является .NET Domain-Driven Design with C #, Problem — Design — Solution написанная Tim McCarthy.

В этой книге вы наёдете практические примеры:

1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода

2) Как организовывать архитектурные слои в своих решениях

3) Как применять шаблоны и практику DDD

4) Как построить небольшой каркас для DDD

5) Как изолировать домен предметной области от модели

6) Современные представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight ) в практике.

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

Вся концепция книги построена на 3 книгах-столпах DDD:

1. PoEAA Мартина Фаулера
2. DDD Эрика Ивенса
3. Applying Domain — Driven Design and Patterns от Jimmy Nilsson’s («Применение шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C # и.NET ”Джимми Нильссона)

В этой книге поверхностно рассмотрены все вопросы, техники и паттерны, применяемые в DDD, все примеры используются кодом, что упрощает понимание. Книга превосходная, однако русский перевод подкачал, поэтому, рекомендую прочитать оригинал.

Однако DDD — это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо выполнить, если вы решили выполнять DDD, как фокусирование на высоком приоритетном отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д… это является основным ознакомлением с книгой Эрика Ивенса, так как она вам более объемное и глубокое понимание философии DDD.

DDD не привязанны к используемым технологиям, однако соблюдать DDD будет не так просто, без наличия хороших средств и практик в вашем арсенале, таких как: TDD-фреймворк, ORM, возможность независимости реализации сохраняемости (Persistence Ignorance), IoC-контейнер (Инверсия управления), и возможности AOP (Аспектно-Ориентированного Программирования), конечно не все эти инструменты нам понадобятся, они приблизят нас к реализации DDD на практике.Практичная ценность этих средств в том, что они позволяют изолировать модель предметной области, что является ключевой целью DDD. Книга Джимми Нильссона может познакомить вас с возможностями и предоставлением данных инструментов. Джимми так же показывает как использовать шаблоны реализации корпоративных приложений, и строить, благодаря им, цельное решение, основанное на современных инструментах и ​​практиках.

Некоторые реализации шаблонов DDD на Ruby On Rails:

Некоторые концепции DDD (Domain Driven Design) реализованы в Rails

4.Актуальные вопросы DDD

C DDD так же связать такую ​​тему, как DDDD: Распределенный DDD. DDDD — это DDD в распределенных сценариях. В настоящее время существует не так много ресурсов, посвященных DDDD, в нескольких словах о DDDD: покрывает проблему реализации сообщений и DDD, разделение команд и запросов (Command Query Separation (CQS)) помогает реализовать данный подход. Грег Янг (Грег Янг) сообщил, что готовит книгу, посвященную DDDD.

SOA и DDD — это ещё одна объемная тема, часто обсуждаемая Udi Dahan

5.DDD шаблоны, концепции и понятия

В промышленных приложениях DDD использует ряд шаблонов, часть которых описана в книге Эрика Ивенса, это не отменяет применение объектно-ориентированного подхода, включающего GoF-шаблоны, шаблоны Мартина Фаулера, описанные в его PoEAA, Шаблоны интеграция корпоративных приложений и т.д.…

Вот некоторые из них:

6. Примеры приложений

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

Вот они:

1) Приложение Тима Маккарти его проект, описанный в деталях в его книге. Он не только применение шаблонов, но так же акцентирует внимание в разработке модели предметной области с точки зрения DDD.

Проект так же интересен тем, что построен на .NET 3.5 и демонстрирует всю силу современного подхода связывания данных с моделью предметной области (привязка данных, реализация шаблона MVVM).Так же его стиль примечателен умением выделять абстракции и повторно использовать код.

2) Следующий проект, на который следует обратить внимание — это приложение разработанное Yves Goeleven, создание данного приложения описано в его блоге (так же посвященному основным концептам DDD). Другим его приложение является DDD-каркас. Следует обратить внимание на его выполнение шаблонов Репозиторий и Спецификация.

3) Билли Маккафферти представляет потрясающий открытый фреймворк, сфокусированный на DDD, под названием S # arp Architecture.У него есть очень хорошее описание, включающее в себя описание шаблонов и подходов, заключенных в фреймворке. Фреймворк нацелен на приложения ASP.NET MVC с применением NHibernate.

4) Пример приложения C # Domain-Driven Design (ndddsample), это приложение, разрабатываемое Джимми Нильссоном, демонстрирует разбиение приложения на ключевые слои с точки зрения DDD. Так же демонстрируется практическое применение шаблонов, стандартный блок в предметной области перевозки грузов, описанной в его книге.

Этот проект основан на совместной работе компании Эрика Ивенса «Domain Language» и шведской консалтинговой компании «Citerus».

Цель этого проекта:

• Показать практическое применение DDD с применением .NET.
• Использование актуальных утилит, технологий и методологий разработки в области .NET, обсуждаемых ALT.NET-коммунити.
• Привести практические примеры реализации типовых DDD приложений.
• Показать способ реализации DDD на платформе, что позволит без труда осуществить самое на любой другой другой платформе.
• Помочь в выборе реализуемых практик. Различные подходы позволят обсудить их и выбрать подходящие варианты для реализации.

здесь более подробная информация.

7. Ресурсы по Domain Driven Design

Официальный сайт — http://domaindrivendesign.org/

Группа обсуждений — http://tech.groups.yahoo.com/group/domaindrivendesign/ это взрослая группа, очень хороший источник идей , место для обсуждения всех видов проблем в области DDD.В ней на ваши вопросы могут ответить опытные в DDD люди, даже Эрик Ивенс :-).

Блог Jimmy Bogard’а — http://www.lostechies.com/blogs/jimmy_bogard/default.aspx

Блог Colin Jack’а — http://colinjack.blogspot.com/

Блог Greg Young’а — http://codebetter.com/blogs/gregyoung/default.aspx

Блог Casey Charlton’а — http://devlicio.us/blogs/casey/

Блог Udi Dahan’а — http: // www. udidahan.com/

Введение в доменно-ориентированный дизайн — http: // msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

8. Заключение

Если вы согласны в расширении ваших «объектно-ориентированных горизонтов» в сложных корпоративных системах и изучении новых способов разработки и проектирования, то DDD — именно то что нужно.

http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx

.