PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Send a file File manager PDF Toolbox Search Help Contact



Вернон Предметно ориентированное проектирование. Самое основное .pdf



Original filename: Вернон - Предметно-ориентированное проектирование. Самое основное.pdf

This PDF 1.6 document has been generated by / Adobe Acrobat 9.33 Paper Capture Plug-in, and has been sent on pdf-archive.com on 12/01/2019 at 01:36, from IP address 103.231.x.x. The current document download page has been viewed 62 times.
File size: 101.8 MB (157 pages).
Privacy: public file




Download original PDF file









Document preview


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

~@~ ~@~!НJ@~



о

аlП•

eSI



Гlvеп
••

IS 1 е

Vaughn Vernon

••• Addison-Wesley
80ston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Саре Town
Dubai • l ondon • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City
Sao Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo

е

о

иенти
п

ованное

оекти

~~

о

метно­
ование

о ~Ll r О [85[}={] О t.=:::J
Вон Вернон

Москва. Санкт-Петербург. Ки е в

2017

ВВК

32.973.26-0 18.2. 75

В35
УДК681.3.07

Компьютерное издательство "ДИалектика"
Зав. редакцией С.Н. Трuгуб
Перевод с английского и редакция докт. физ. -мат. наук Д.А Клюшuна
По общим вопросам обращайтесь в издательство "Диалектика" по адресу:

Iпfо@dlalеktikа.соm.

http:/ /www.dialektlka.com

Вервов. Вон.

В35

Предметно-ориентированное проектировани е : самое основное.
сангл. -СпВ.:

000

"Альфа-книга".

2017. -

:

Пер.

160с.: ил. -Парал. тит. англ.

ISBN 978-5-9908463-8-8 (рус.)
ББК

32.973.26-018.2.75

Все названия программных ПРОдУКТов ЯВllяются зарегистрированными торговыми марка­
ми соответствующих фирм.

Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в ка­

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

Addison-Wesley Pиblishlng Сотрanу. Inc.
Authorlzed tгanslatlon from the English language edltlon published Ьу АddJsоп-Wеslеу
Pиblishing Сотрапу. Inc. © 20 16 Ьу Pearson Education. Inc.
АН rights reserved. 111Js publJcatlon is protected Ьу copyright. and permlsslon must Ье obtalned
from the publlsher prior to anу proh.ibited reproductlon. storage in а retrieval system. ог transmlssion in апу form ог Ьу anу means. electronlc. mechanical. photocopying. recording. ог likewise.
Rights to thls book were obtalned Ьу arrangement with Pearson Educatlon. Inc.
Russian language еdltlоп pubUshed Ьу Dialektlka Computer Books РиЫishiпg ассогdiпg to the
Agгеетепt with R&I Епtегрrisеs Iпtеmаtlопal. Copyright © 20 17
менного разрешения издательства

Научно-гюnулярное издание
ВонВернон

Предметно-ориеН"I'ированное
проектированиесамоеосвоввое
Литературный редактор

И.А Поrwва

Верстка

М.А YlJалов

Художественный редактор

В.г. Павлюmuн

Корректор

л.А Гордиенко

Отпечатано в АО . Первая Образцовая типография .

Филиал . ЧеховскиЙ Печатный Двор'

142300.

1
8(499)270-73-59

Москов с кая область. г. Чехов. ул. Полиграфистов. д .

Сайт: www.c hpd .ru.E-mаll:salеs@сhрd .гu. тел.

000 "Альфа-книга". 195027.

ISBN 978-5-9908463-8 -8 (рус . )
ISBN 978-0-13-443442- 1 (англ . )

Санкт-Петербург. Мarнитогорская ул .. д.

©

30

Компьютерное издательство "ДИалектика".

© Реагsоп

Еduсаtlоп.

Inc .. 2016

2017

Оглавление
Предисловие

10

Благодарности

14

06

авторе

ГЛАВА

15

1

Краткий обзор

-

ГЛАВА

DDD

17

2

Стратегическое проектирование
с помощью ОГРАНИЧЕННЫХ КОНТЕКСТОВ и ЕДИНОГО ЯЗЫКА

ГЛАВА

3

Стратегическое проектирование с помощью ПОДОБЛАСТЕЙ

ГЛАВА

27

61

4

Стратегическое проектирование
на основе СВЯЗЫВАНИЯ КОНТЕКСТОВ

ГЛАВА

5

Тактическое проектирование с помощью АГРЕГАТОВ

ГЛАВА

67

89

6

Тактическое проектирование
~

~

с помощью СОБЫТИИ ПРЕДМЕТНОИ ОБЛАСТИ

ГЛАВА

113

7

Инструментальные средства для повышения

эффективности проектирования

125

Библиография

151

Предметный. указатель

153

Содержание
Предисловие

10

Для кого предназначена эта книга

11

Темы. рассмотренные в книге

12
13

Соглашения

Благодарности

14

Об авторе

15

ГЛАВА

1

Краткий обзор

DDD

17

Вреден ли ООО?

18
19
23
24

Хороший. плохой и эффективный дизайн
Стратегическое проектирование
Тактическое проектирование

Процесс обучения и уточнения знаний

25
26

Поехали!

ГЛАВА

2

Стратегическое npоектирование с помощью ОГРАНИЧЕННЫХ
КОНТЕКСТОВ И ЕДИНОГО ЯЗЫКА

27

34
37

Эксперты проблемной области и бизнес-факторы
Типичный пример

Необходимость фундаментального стратегического

41
4551
55
57
57
59

проектирования

Ставьте проблемы и обобщайте
Разработка ЕДИНОГО Я ЗЫКА
Реализация сценариев

Далекие перспективы
Архитектура

Резюме

ГЛАВА

3

-

Стратегическое npоектирование с помощью ПОДОБЛАСТЕИ
Что такое ПОДОБЛАСТЬ

Типы ПОДОБЛАСТЕЙ
Проблема сложности системы
Резюме

61

62
62
63
66

Содержание

ГЛАВл4
Стратегическое npоектирование
на основе СВЯЗЫВАНИЯ КОНТЕКСТОВ

67
69
70
70

Способы связ ывания контекстов
ПАРТНЕРСТВО
ОБЩЕЕ ЯДРО

КОНФОРМИСТ

71
71

ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ

72

СЛУЖБА С ОТКРЫТЫМ ПРОТОКОЛОМ

73
73

КЛИЕНТ - ПОСТАВЩИК

ОБЩЕДОСТУП НЫЙ ЯЗЫК
ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ

БОЛЬШОЙ КОМ ГРЯЗИ
Правильное использование СВЯЗЫВАНИЯ КОНТЕКСТОВ

Удаленный вызов процедур по протоколу

SOAP

Протокол RESТful Н1ТР
РАССЫЛКА СООБЩЕНИЙ
Пример СВЯЗЫВАНИЯ КОНТЕКСТОВ

Резюме

74
74
76
77
78
80
85
88

ГЛАВл5
Тактическое проектирование с помощью АГРЕГАТОВ
Заче м нужны АГРЕГАТЫ

89
90

Эмпирические правила проектирования АГРЕГАТОВ

95

Правило

1.

Защищайте бизнес-инварианты

в границах АГРЕГАТА

2.
Правило 3.
Правило

Проектируйте маленькие АГРЕГАТЫ
Ссылайтесь на другие АГРЕГАТЫ только

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

4.

95
97
98

Обновляйте другие АГРЕГАТЫ . руководствуясь
u

принципом итого во и согласованности

Моделирование агрегатов
Тщательно выбирайте абстракции
Агрегаты правильного размера
Тестируемые модули

Резюме

99
102
107
109
111
112

ГЛАВл6
Тактическоеnpоектирование
u

u

С помощью СОБЫТИИ ПРЕДМЕТНОИ ОБЛАСТИ

113

Прое ктирование. реализация и использование

СОБЫТИЙ ПРЕДМЕТНОЙ ОБЛАСТИ

114

Содержание

ИСТОЧНИКИ СОБЫ ТИЙ
Резюме

ГЛАВА

121
123

7

Инструментальные средства для повышения эффективности

125

проектирования

СОБЫТИЙ НЫЙ ШТУРМ
Други е ин струменты

Прим е не ние принципов ООО для гибкого проектирования
Начне м с начала
И с пол ьзование

swar-анализа

Вс плес ки и долги моделирования

Идентификация задач и оценивание
Модел ировани е с ограничением времени
Реали зация

Взаимоде йстви е с ЭКСПЕРТАМИ ПРЕДМЕТН О Й ОБЛАСТИ
Резюм е

126
138
138
140
140
142
143
145
146
148
149

Библиография

151

Предметный указатель

153

Посвящается НИКОЛЬ И ТРИСТан!
Мы сделалИ это снова!

Предисловие
Почему моделирование

-

такое увлекательное и приятное занятие? Еще

в детстве я любил конструировать модели. Тогда я собирал. как правило.
модели автомобилей и самолетов. Я не уверен. что конструктор

существовал в те дни. Однако

LEGO был важной

LEGO

уже

частью жизни моего сына.

когда он был маленьким. Кон струировать и собирать модели из маленьких

кубиков было очень интересно. Сначала вы строите элементарные модели.
а потом вам кажется. что ваши идеи можно развивать до бесконечности.

Вероятно. каждый человек в детстве проходил через это увлечение.
Модели возникают в очень многих жизненных ситуациях. Если вы лю­

бите играть в настольные игры. то используете модели. Это могут быть мо­
дели недвижимого имущества и его владельцев. или островов и выживших

людей. или территорий и строительства. и кто знает. что еще. Точно так же
видеоигры- это модели. Они моделируют сказочный мир с причудливыми
персонажами. играющими фантастические роли. Даже колода карт и кар­

точные игры моделируют власть. Мы настолько часто используем модели.
что. как правило. не осознаем этого. Модели

-

это часть нашей жизни.

Но почему? У каждого человека есть свои особенности восприятия.
Существует множество видов восприятия. но среди них есть три главные

-

слух. зрение и осязание. Люди. воспринимающие реальность через слух.
познают мир. слыша и слушая. Люди. у которых превалирует зрительное

восприятие.

обучаются.

читая или видя образы. Люди.

щие реальность через осязание.

воспринимаю­

получают знания. прикасаясь к чему-то.

Интересно. что у каждого человека один из этих видов восприятия господ­

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

могут не вспомнить. что при этом говорили окружающие. Может показать­

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

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

делей доступна для людей с любыми особенностями восприятия.
С нашей врожденной склонностью к восприятию реальности с помощью
создания моделей совершенно естественно возникает желание моделиро­

вать программное обеспечение. которое играет все большую роль в нашей

Предисловие

жизни. Моделировать программное обеспечение

-

нормальное занятие

для человека. И мы должны это делать. Мне кажется. что все люди могут
быть прекрас ными разработчиками моделей программного обеспечения.
Я очень хочу помочь читателям.

насколько это возможно.

проявить

свои лучшие качества в моделировании программного обеспечения с по­

мощью самых эффективных из доступных средств nредмеmно-ориенmи­
рованного nроекmuрованuя. или

DDD (domain-driven design).

Этот набор

инструментов. представляющих собой совокупность шаблонов. впервые
был проанализирован Эриком Эвансом (Епс

Evans)

в книге

Domain-Driven

Design: Tackling Coтp/exity in the heart oJ SoJtшаге 1 • Я бы хотел. чтобы прин-

_ципы

ооо освоил каждый разработчик. Если это значит. что я хочу вне­

дрить принципы ооо в массы. пусть так и будет. ООО заслуживает этого.

ООО

-

это инструментарий. которые люди имеют право использовать для

создания самых сложных моделей программного обеспечения. Я написал
эту книгу. чтобы сделать изучение и использование ООО максимально проv

v

стым И доступным для само и широкои аудитории.

Для людей. воспринимающих мир с помощью слуха. ООО открывает

возможность обучения на основе общения в ГРУllпе разработчиков модели.
создающих ЕДИНЫЙ ЯЗЫК (UВIQUITOUS LANGUAGE). Люди. воспринимающие
v

реальность с помощью зрения и осязания. оценят визуальныи и тактиль-

ный характе р процесса использования инструментальных средств ООО
для стратегического и тактического проектирования. Это особенно ярко
проявляется при создании КАРТ КОНТЕКСТОВ

(CONTEXT

МAPS ) и моделирова­

нии бизнес-процес сов с помощью СОБЫТИЙНОГО ШТУРМА ( EVEN T STORMING).
Таким образом. я полагаю. что ООО может удовлетворить потребности
каждого. кто хочет учиться и достичь успеха с помощью разработки моv

делеи.

Для кого предназначена эта книга
Эта книга предназначена для тех. кто хочет быстро изучить самые важ­
ные аспекты и инструменты ООО. Целевая аудитория этой книги

-

архи­

текторы и разработчики программного обеспечения. желающие внедрить
принципы ООО в свои проекты. Очень часто разработчики программного
обеспечения быстро распознают преимущества ООО и оценивают по дос­
тоинству его мощь. Несмотря на это. я стремился раскрыть эту тему и для

остальной аудитории

-

руководителей. экспертов предметной области. ме­

неджеров. бизнес-аналитиков. архитекторов информационных систем и

I

Русский п е р е вод: Эванс Э. Предметно-ориентированное проектирование

(000):

444 с. -

структуризацuя сложных программных систем.

Примеч. ред.

-

М.: Вильяме.

2011. -

Предисловие

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

Если вы

-

консультант и работаете с клиентом, которому ре комендуе­

те использовать

000,

то используйте эту книгу как средство, позволяюще е

быстро донести основные идеи до заинтересованных сторон. Если над ва­

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

000,

но должны его очень бы­

стро освоить, посоветуйте им эту книгу. Как минимум, прочитав эту книгу,

все заинтерес ованные стороны и разработчики будут использовать одни и
те же термины и знать ос новны е инструменты
ность осознанно использовать

000.

Это даст им возмож­

000 в ходе совместной работы на проектом.

Независимо от вашего опыта и роли в проекте, про читайте эту книгу, а

затем примените

000

на практике. После этого снова перечитайте книгу

и выясните, что оказалось полезным и как это можно улучшить.

Темы, рассмотренные в книге
в главе

1,

·КраткиЙ обзор

000",

я объяс няю, чем

000

может быть по ­

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

краткий обзор того, чему вы будете учиться и почему это важно для вас.
IЛава

2,

·Стратегическое проектирование с

помощью ОГРАНИЧЕННЫХ

КО Н ТЕКСТ О В и ЕДИН О Г О ЯЗЫКА", посвящена вопросам стратегичес кого пред­
метно-ориентированного про е ктирования на о с нов е е го краеугольных кам­

ней: ОГРАНИЧЕННЫХ КОНТЕКСТОВ и ЕДИНОГО ЯЗЫКА . В главе

3,

·Стратегическое

проектирование с помощью П ОДО БЛАСТЕЙ ", объясняется концепция подо ­
БЛАСТЕЙ и с пособы е е и с пользования для упрощения интеграции унасле ­
дованных систем с новыми приложениями. IЛава

4,

"Стратегическое про­

ектировани е на основе С ВЯЗЫВАНИЯ КО НТЕКСТ О В ". опис ывает разнообразие

способов организации стратегического сотрудничества групп и объеди­
нения их программного обес печения. Эта концепция называется СВЯЗЫ ­
ВАН И Е М КОНТЕКСТОВ .

IЛава

5,

"Тактиче с кое проектирование с помощью

АГР ЕГАТ О В ," переключает ваше внимание на тактическое моделирование и

АГ Р Е ГАТЫ . Важный и мощный тактический инструмент моделирования, ко~

торыи ис пользуется вместе с АГРЕГАТАМИ ,

являются те мой главы

6,

-

"
СОБЫТИЯ ПРЕДМЕТН ОИ О БЛАСТИ ,

"Тактич ес кое проектирование с помощью СОБЫТИЙ

ПР ЕДМ Е ТН ОЙ О БЛАСТИ". Наконец, в главе

7,

·Инструментальные средства для

повышения эффективности проектирования", описываются инструменты,
предназначенные для ускорения и управления про е ктами,

которые могут

помочь группам установить и подде рживать правильный темп работы. Эти

Предисловие

000. но они
кто настроен внедрить 000 в практику.

две темы редко обсуждаются в других источниках по
ленно необходимы для тех.

опреде­

Соглашения
В книге принято лишь несколько соглашений. Все шаблоны

000.

ко­

торые мы будем обсуждать. набраны ПР О ПИС НЫМИ БУКВАМИ . Например. вы

будете читать об О ГРАНИЧЕННЫХ КО НТЕК С ТАХ и СО БЫТИЯХ ПРЕДМЕТН О Й ОБ ­
Л АСТИ. Другое соглашение касается фрагментов кода

-

они выделены

мо н о ширинным шрифт ом . Аббревиатуры источников. которые приведены в

_ библиографии. указаны

в главах в квадратных скобках.

Кроме того. в книге особое внимание уделяется многочисленным диа­
граммам и рисункам. которые обычно воспринимаются читателями лучше.
чем текст. Обратите внимание на то, что рисунки не пронумерованы, пото­
му что я не хотел смущать читателей их большим количеством. Рисунки и
диаграммы всегда предшествуют их обсуждению в тексте, так что опреде­

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

ку или диаграмме для визуальнои поддержки.

Благодарности

Благодарности
Это уже третья моя книга. опубликованная уважаемым издательством

Addlson-Wesley.

Кроме того. я в третий раз работаю с моим редактором

Крисом Гузиковски
3аном

(Chris Zaп).

(Chris Guzikowski)

и техническим редактором Крисом

Я счастлив сказать, что третий раз был таким же прият­

ным. как первые два. Еще раз спасибо за выбор моей книги для публикации.
Ни одна книга не может быть успешно написана и издана без кри­
тических замечаний. На сей раз я обратился к практикам ООО. Это не
всегда были преподаватели или авторы книг и статей. но эти люди игv

рали важную роль в проектах. помогая другим использовать мощныи ин-

струментарий ООО. Я считал. что именно практики должны подтвердить

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

60

минут, дайте мне

на подготовку. а если вы хотите, чтобы я выступал в течение

5

5

минут

минут. дайте

мне на подготовку несколько часов.

Далее в алфавитном порядке перечислены те, кто помогал мне больше

всех: Джереми Чассен
Юджи Кирики

(Jeremie Chassaing).

Брайен Данлэп

(Brian Danlap),

(Yuji Кiriki), Том Стоктон (10т Stockton). ТормодДж.
вик (TOllIlOd J. Varhaugvik), Даниэль Вестхайде (Daniel Westheide)
Уиндли (Philip Windley). Большое спасибо!

Вархауг­

и Филип

Об авторе

Об авторе
Вон Вернон

-

ветеран программирования и авторитетный эксперт

в области упрощения проектирования и реализации программного обес ­
печения. Он автор бестселлера

Reactive Messaging Patterns
в издательстве

шith

Addison-Wesley.

Implementing Domain-Driven Design and
the Actor Model, также опубликованного

Он организовал семинар

IDDD Workshop,

который про водится по всему миру для сотен разработчиков программно-

-го обеспечения. Вон часто выступает на профессиональных конференциях.

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

предметно-ориентированному проектированию,

пользуя модель акторов вместе с языком

ScaJa

и каркас

следить за работами Вона, читая его блог по адресу
и сообщения в Твиттере по адресу

@VaughnVernon

Akka.

ис­

Вы можете

www . Vaughn Vernon . со

Глава

1

I<раткий обзор

DDD

я уверен. что вы хотите улучшить свое мастерство и закрепить успех

своих проектов. Бы стремитесь повысить конкурентоспособность своего
бизнеса за счет нового программного обеспечения. которое разрабатыва•

ете. Бы хотите реализовать программное обеспечение. которое не только
правильно моделирует операции вашего бизнеса. но и обеспечивает мас­
штабирование на основе самой современной программной архитектуры.

Для того чтобы достичь этих целей. вам необходимо быстро освоить основы
предметно-ориентированного проектирования

000 -

(000).

это инструментарий. помогающий проектировать и реализо­

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

быть лучшей во всем. следовательно. необходимо тщательно выбрать обла­
сти. в которых она должна быть лучше других. Инструменты стратегичеv

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

группе принимать наиболее эффективные решения. связанные с разработ­
кой и интеграцией программного обеспечения. Баша организация извлеv

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

ют ее специализацию. Средства тактического предметно-ориентированно­
го проектирования могут помочь вам и вашей группе разрабатывать мак­

симально полезное программное обеспечение. точно моделирующее уни­
кальные бизнес-операции. Баша организация должна извлечь выгоду из
широкого

v

спектра возможностеи.

связанных с

развертыванием

v

решении

в разнообразных инфраструктурах как внутри компании. так и в облаке.

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

000,

рассматривая как стратегические,

так и тактические инструменты моделирования. Я понимаю уникальные

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

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

Глава 1. Краткий обзор DDD

я

-

автор бестселлера Implementiпg

того, я организовал и

Domain-Driven Design [IOОО]'. Кроме
провожу трехдневный семинар IDDD Workshop. Я на­

писал эту книгу. чтобы изложить принципы ооо в максимально сжатом

виде. Это мой вклад в дело внедрения ООО в практику каждой группы раз­
работчиков программного обеспечения. где это уместно. Моя цель. конеч­

но.

-

объяснить вам основы ООО.

j

Вреден ли

DDD?

Возможно. вы слышали, что ООО

-

сложный подход к разработке про­

граммного обеспечения. Сложный? Он не сложнее задач. для решения ко ­
торых предназначен. Действительно. ООО

-

это совокупность передовых

методик. которые используются при разработке сложного программного
обеспечения. С учетом мощи и масштаба этого подхода для его самостоя­
тельного изучения без помощи эксперта вам потребуется так много усилий.
что это может отпугнуть вас от его освоения. Вы. вероятно. также думаете.

I

Русс кий п е ревод: Вернон В.

ного проектированuя.

-

Реализация меmoдО6 предметно-ориентирован­

М.: Вильяме.

2016. - 688 с. -

Прuмеч. ред.

Глава

что другие книги по

1. Краткий обзор DDD

000.

содержащие сотни страниц. очень трудно понять

и применить полученные навыки на практике. Мне пришлось затратить

000

много слов. чтобы подробно объяснить

и дать его исчерпывающее

описание. осветив более десятка специальных тем и шаблонов. В резуль­
тате этих усилий в свет вышла книга

IIDDDI.

Implementing Domain-Driven Design

Эта новая лаконичная книга должна ознакомить вас с самыми важ­

ными частями

000 так быстро и

просто. насколько это возможно. Почему?

Потому что многих читателей угнетают длинные тексты. Им нужны крат­
кие справочники. чтобы немедленно присrynить к освоению новых мето­
дов. Я выяснил. что специалисты. использующие ооо. перечитывают кни­
J;'и по нескольку раз. Вы можете подумать. что полностью изучить ооо не ­

возможно. и поэтому станете использовать эту книгу как справочник. обра­

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

000 своим коллегам и менеджерам. Эта книга поможет вам сделать это. не
только объясняя 000 в сжатом виде. но и демонстрируя доступные инстру­
ментальные средства. позволяющие ускорить проектирование и обеспе­
чить его управляемость.

Конечно. по этой книге нельзя пройти полный курс по DОО. потому что
я преднамеренно изложил методики ОDО в сжатом виде. Для более глубо­

кого изучения этого подхода обратитесь к моей книге

Driven Design IIDDD]

shop.

или запишитесь на

Implementing Domainтрехдневный семинар IDDD Work-

Трехдневный интенсивный курс. который я провожу по всему миру

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

htt p: // f or Compre he nsion . сот .

Хорошие новости заключаются в том. что ооо не должен повредить

вам. Поскольку вы. вероятно. уже столкнулись со сложностью В ваших про­
ектах. вы можете учиться использовать

000.

чтобы преодолеть сложность

с помощью менее болезненных средств.

Хороший, плохой

и эффективный дизайн
Люди часто говорят о хорошем и плохом дизайне. К какой категории

проектов относится то. что делаете вы? Многие группы разработчиков про­
граммного обеспечения даже не думают о дизайне. Вместо этого они дела­
ют то. что я называю "перетасовкой задач на доске"

("taskboard s huff1e").

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

Scrnm.

или бэклога продукта

(backJog).

и пе­

ремещают стикер из столбца "В планах" в столбец "В работе". Разработчики

Глава

1.

Краткий обзор

DDD

глубокомысленно перетасовывают пункты списка в бэклоге продукта. а
про грамм исты тем временем все это героически кодируют. Результат ред­
ко совпадает с ожидаемым. а биэнес обычно платит самую высокую цену за
отсутствие проектирования.

Это часто происходит из-за слишком напряженного календарного плана

выпусков программного обеспечения. когда менеджеры используют мето­
дологию

Scrum

в основном для контроля за графиком работ и пренебрега­

ют одним из самых важных принципов

Scrum:

приобретением знаний.

Когда я консультирую или преподаю в отдельных компаниях. я часто
OJ'"

'V

.....

сталкиваюсь с однои и тои же ситуациеи: программныи проект находится

под угрозой, и все группы разработчиков нацелены на обеспечение работо­

способности системы с помощью ежедневного исправления кода и данных.
Ниже перечислены некоторые из коварных проблем. которые подстерега­

ют разработчиков и которые

000

позволяет избежать. Я начинаю с биз­

нес-проблем высокого уровня и заканчиваю более техническими задачами.



Разработка программного обеспечения считается статьей расходов. а
не источником прибыли. Это объясняется тем. что бизнес часто рас­
сматривает компьютеры и программное обеспечение как необходи­

мый атрибут. а не источник стратегических преимуществ. (К сожале­
нию. если такая бизнес-культура глубоко укоренилась в компании. то.
вероятно. эту ситуацию исправить невозможно.)



Разработчики слишком погружены в технические вопросы и пытают­
ся устранять проблемы. используя технологию. а не трезвый расчет и
продуманный дизайн. В результате они постоянно гоняются за новы­
ми "блестящими штучками"



-

последними причудами технологии.

Базе данных присваивается слишком высокий приоритет. и боль­
шинство обсуждений возможных решений сосредоточивается на базе
данных и модели данных вместо бизнес-процессов и операций.



-

Разработчики не придают наДlIежащего значения правильному наи­
менованию объектов и операций в соответствии с бизнес-целью. для

которой они предназначены. Это ведет к большой пропасти между
ментальной моделью бизнес-экспертов и программным обеспечени­

ем. которое поставляют разработчики.



Предыдущая проблема является следствием плохого сотрудничества с
бизнес-экспертами. Часто бизнес-эксперты тратят слишком много вре­

мени на обособленную работу над спецификациями. которые либо не
используются разработчиками вообще. либо учитываются частично.



Слишком большое значение

приписывается сметам

проектов.

на

создание которых тратятся значительные усилия и объемы време-

Глава 1. Краткий обзор DDD

ни. что приводит К задержке поставок программного обеспечения.
Вместо продуманного проектирования разработчики перетасовыва­

ют задачи на доске. Они создают БОЛ ЬШОЙ КОМ ГРЯЗИ (обсуждаемый в
следующих главах) вместо правильного разделения модели в соответ­
ствии с бизнес-факторами.



Разработчики помещают бизнес-логику в компоненты пользователь­
ского интерфейса и хранения данных. Кроме того. они часто выпол­
няют операции. связанные с хранением данных в бизнес-логике.



в системах возникают испорченные. MeДJ1eHHыe и вызывающие бло­
кировку запросы к базе данных. не позволяющие пользователям вы­

-

полнять бизнес-операции. чувствительные к задержкам.



Разработчики

используют

неправильные

абстракции.

пытаясь

учесть все существующие и предполагаемые потребности. чрезмерно
обобщая решение. вместо того. чтобы обратиться к конкретным биз­
нес-потребностям.



в системе используются сильно связанные службы. в которых опера­

ция выполняется одной службой. а затем эта служба непосредственно
вызывает другую службу для выполнения балансирующей операции.
Эта связь часто разрушает бизнес-процессы и по рождает несогласо­
ванные данные. не говоря уже о том. что такие системы очень трудно

обслуживать.
Все это кажется результатами отказа от проектирования с целью уде­

шевления программного обеспечения. Слишком часто это является следст­
вием неправильных бизнес-решений. принятых руководством компании и
разработчиками программного обеспечения. которые не знают о сушество­
вании намного лучшей альтернативы. "Программное обеспечение пожира­

ет мир"

[WSJ].

а значит. и вашу прибыль.

Важно понять что предполагаемая экономия за счет отказа от проекти­

рования

-

это ложная идея. вводящая в заблуждение тех. кто настаивает

на производстве программного обеспечения без продуманного дизайна.
Все это происходит потому. что понимание важной роли проектирования
~

все еще является достоянием немногих людеи.

и пока не оказывает влия-

ния на остальных людей. включая бизнесменов. Я думаю. итог следует под~

вести с помощью следующеи цитаты.

Вопросы о moм. необходим ли дизайн или доступен. не имеют смысла:
дизайн неизбежен. Альтернатива хорошему дизайну

-

плохой дизайн.

а не отсутствие дизайна вообще.

Book Design: А Ргасticаllntгodисti.on Ьу Doиglas Martin

Глава

1.

Краткий обзор ООО

Хотя комментарии Дугласа Мартина относятся не к проектированию

программного обеспечения. они все же применимы к нашему ремеслу. где
нет никакой альтернативы ПРОдУМанному дизайну. В ситуации. описанной
выше. если над проектом работают пять разработчиков. то отказ от проек­

тирования не приведет к объединению пяти разных дизайнов в одном. Вы
просто получите смесь пяти разных искусственных интерпретаций бизнес­
языка без выгоды от привлечения реальных ЭКСПЕРТ О В ПРО БЛЕМНОЙ О БЛАС ТИ .
Подведем итог. Мы занимаемся моделированием независимо от того.
признае м мы это или нет. Это можно сравнить с тем. как возникают и ис­

чезают дороги. Некоторые дороги в далеком прошлом были оживленными
транспортными магистралями.

а потом постепенно зарастали и в конеч­

ном счете превращались в заброшенные тропы. Они делали необъяснимые
повороты и разветвления. по которым ходили немногие путешественники.

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

настолько неудобным и некомфортным. Современные дороги спланирова­
ны и спроектированы в результате ПРОдУМанных исследований населения.

окружающей среды и прогнозируемых транспортных потоков. Оба вида до­

рог были результатом моделирования. Однако в первом случае интеллект
и с пользовался

в

~

минимальнои

степени,

а

во

втором

-

в

~

максимальнои.

Программное обеспечение можно моделировать точно так же.

Если вы опасаетесь. что создание программного обеспечения на основе

ПРОдУМанного проектирования связано с большими расходами. ПОдУМайте.
насколько дороже обойдется использование или даже исправление плохо­
го дизайна. Это особенно относится к программному обеспечению. кото­
рое должно вьщелить вашу организацию среди всех других и принести вам

значительное конкурентоспособное преимущество.
Со словом хороший тесно связано слово эффективный. Возможно. вто­
рое слово более точно выражает цель. к которой следует стремиться: эф­

фективный дизайн. Он удовлетворяет потребности организации настоль­
ко. что позволяет ей получить конкурентное преимущество благодаря про­
граммному обеспечению. Стремление создать эффективный дизайн выну­
ждает организацию выяснить. какие аспекты обеспечивают ее превосход­
ство и использовать их в качестве ориентира при разработке правильной

модели программного обеспечения.
В методологии

Scrum

npиобреmeние знаний осуществляется с помощью

экспериментирования и совместного изучения предметной области и на­

зывается ·приобретением информации"

[Essential

Sсгиml. Знание никогда

Глава 1. Краткий обзор ооо

не бывает бесплатным. но в этой книге я объясню. как ускорить его прио­
бретение.
На всякий случай. если вы все еще сомневаетесь в том. что эффектив­
ный дизайн имеет большое значение. вспомните высказывания тех. кто.
кажется. понимает его важность.

·Вольшинство людей делают ошибку. думая о дизаЙн.е. как о внешн.ем

виде. Люди думают. ч.та эта видимость. ч.mо дизаЙн.еру дают коробку и
говоряm: ·СделаЙ так. ч.табы она ВЫ2лядела хорошо!» Эта не та. ч.та мы
называем дизайном. Дизайн
тие вещи. Дизайн

-

эта не просто вн.ешниЙ вид или восприя­

эта та. как она работает".

-

СтивДжобс
В программном обеспечении эффективный дизайн имеет огромное зна­

чение. Принимая во внимание альтернативу. я рекомендую эффективный
дизайн.
Ограниченный контекст



Единыйязык

Стратегическое проектироваиие
Мы начинаем со стратегического проектирования. важного во всех от­

ношениях.
рование.

Невозможно

если

сначала

эффективно
не

применять

выполнить

тактическое

стратегическое

проекти­

проектирование.

Стратегическое проектирование представляет собой картину. написанную

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

Сначала вы узнаете. как выделить МОДЕЛЬ ПРЕДМ Е ТНОЙ ОБЛАСТИ (DOМAIN

MODEL) • используя шаблон стратегического проектирования под названи­
ем ОГРАНИЧЕННЫЙ КО Н ТЕКСТ (BOUNDED CONTEXT). Затем мы покажем. как раз-

Глава

работать Е:ДИНЫЙ ЯЗЫК

1. Краткий обзор ООО

(UBIQUI TOUS LANGUAG E:)

в качестве МОДЕ:ЛИ ПРЕ: ДМЕ:Т ­

НОЙ ОБЛАСТИ в пределах точно определенного ОГРАНИЧЕ:ННОГО КОНТЕКСТА .
Вы узнаете . насколько важно привлекать к работе над Е:ДИНЫМ ЯЗЫКОМ

не тол ько разработчиков, но и ЭКСП Е: РТОВ П РЕ:ДМ Е: Т Н ОЙ ОБЛАСТИ

E:XPERTS) .

Вы увидите,

как

сотрудничают

группы

(DOМAIN

разработчиков

про­

граммного об ес пе чения и ЭКСПЕРТЫ ПРЕДМЕТ Н ОЙ ОБЛАСТИ . Это жизненно
важно е объедин е ние умных и мотивированных людей , которое необходимо
для того, чтобы предметно-ориентированное проектирование принесло на­
илучшие ре зультаты. Язык, который вы разрабатываете , сотрудничая вме­
сте, станет единым и вездесущим языком общения и моделирования.
По м е р е углубле ния в дебри страте гиче с кого проектирования вы столк­
н етесь с поняти е м ПОДОБЛАСТИ ( SUBDOМAIN ) и узнаете , как оно позволяет
с ни з ить

сл ожно с ть

унасл едованных

с исте м

и

достичь

отличных

р езуль­

татов при раз работке совершенно новых проектов. Вы увидите также,
как можно объединить многочи сленные ОГРАНИЧЕННЫЕ КОНТЕКСТЫ с помо­
щью методики под название м СВЯЗЫВАНИЕ КОНТЕК СТОВ
КАРТЫ КОНТЕКСТОВ

(CONTEXT

(CONTEXT

МAPPING).

МAPS ) определяют отнош е ния между коман­

дой и техничес кими механизмами, существующими в двух объединенных
ОГРА НИЧЕННЫХ КОНТЕКСТАХ .

ограниченный контекст

'/-"""""'-..........
Тип агрегата

1

Тип агрегата

2

1

Другой ограниченный
,
контекст

,

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

вания, вы обн а ружите самые мощные с р едства тактич ес кого пр оектирова-

Глава 1. Краткий обзор DDD

ния ООО. Тактическое проектирование можно сравнить с тонкой кисточv

v

кои, которая позволяет прорисовывать мелкие детали вашеи модели пред-

метной области. Одними из наиболее важных являются инструментальные
средства, которые используются для агрегирования сущностей и объектов­

значений в кластер правильного размера. Для этого предназначен шаблон
АГРЕГАТ (AGGREGATE).
Предметно-ориентированное проектирование

описывает моделирова­

ние вашей предметной области самым точным из возможных способов.

Используя СОБЫТИЯ ПРЕДМЕТНОЙ ОБЛАСТИ ( DOМAIN EVENTS), вы сможете точ­
но моделировать предметную область и передавать информацию о том,
'(Го в ней происходит, в другие системы, которые должны знать об этом.
Заинтересованные стороны могут находиться как в вашем ОГРАНИЧЕННОМ
КОНТЕКСТЕ , так и в других отдаленных ОГРАНИЧЕННЫХ КОНТЕКСТАХ .

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

знания

по

мере

изучения

основных

аспектов

вашего

бизнеса. В результате этого процесс а возникают открытия, которые явля­

ются результатом обсуждений и экспериментов. Подвергая сомнению су­
ществующее положение вещей и бросая вызов вашим предположениям о

Глава 1. Краткий обзор DDD

программной модели. ваша группа приобретет обширные и глубокие зна­
ния. Это крайне важные инвестиции в ваш бизнес и вашу группу. Цель со­
стоит не только в обучении и совершенствовании. но и в максимально быс­
тром обучении и совершенствовании. Для достижения этих целей сушест­
вуют специальные инструменты. которые описываются в главе

7.

Поехали!
Даже в сжатом представлении информация о ООО является довольно
обширной . Начнем с главы

2.

"Стратегическое проектирование с помощью

О ГРАНИЧЕННЫХ КОНТЕКСТОВ и ЕДИНОГО ЯЗЫКА" .

Глава

2

Стратегическое
проектирование с помощью

ОГР

ННЫХ КОНТЕКСТОВ

' и ЕДИНОГО

ы АA

Ограниченный контекст

.
,

' '---:-•

. .

Единый язык

,

.

Что такое ОГР АНИЧЕН Н Ы Е КОНТЕКСТЫ и ЕДИНЫ Й ЯЗЫК? В нескольких словах
можно сказать.

что предметно-ориентированное

проектирование прежде

всего подразумевает моделирование ЕДИН О Г О ЯЗЫКА в четко определенном

О ГРА Н ИЧЕНН ОМ К О НТЕКСТЕ . Несмотря на то что это определение совершенно
правильное.

все же.

вероятно. это не самое полезное описание.

мог бы привести. Позвольте мне уточнить сказанное.

Ограниченный контекст

которое я

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Во - первых. ОГРАНИЧЕН Н ЫЙ КОНТЕКСТ -

это семантическая контекстная

граница. Это значит. что в пределах ОГРАНИЧЕННОГО КОНТЕКСТА каждый
компон е нт программного обеспе че ния им еет определе нное значе ние и де ­
лает определенные ве щи. Компоне нты внутри ОГРАНИЧЕННОГО КОНТЕКСТА

являются характерными для данного контекста и семантически обосно­

ванными. Это довольно просто.
Когда вы только ПРИC'I)'Паете к разработке своего программного обес­

пече ния. ваш ОГРАНИЧЕННЫЙ КОНТЕКСТ но с ит пре имущественно теоретиче ­
с кий характер. Его можно интерпретировать как часть вашего простран­

ства задач

(problem space).

Однако . по мере того как ваша модель стано­

вится вс е глубже и яс нее . ваш ОГРА НИЧЕННЫЙ КОНТЕКСТ быстро переходит
в npocтранство реше ний

(solutlon space).

а ваша программная модель от­

ражается в исходном коде прое кта. (Понятия пространства задач и про­

странства ре шений подробн ее объясняются во врезке. приведенной ниже. )
Помните . что ОГРАНИЧЕННЫЙ КОНТЕКСТ -

это область. в котор о й реализует­

ся модель. и каждому ОГРАНИЧЕНН ОМУ КОНТЕКСТУ с оответствует отдел ьный

арте факт программного обеспече ния.

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

-

ческии

анализ

-

это область, в которой осуществляется стратеги-

высокого уровня

и

выполняются

этапы

проектирования

с

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

аграммы. На практике с большим успехом применяются КАРТЫ КОНТЕКС ­

ТОВ . Заметим также, что при необходимости в ходе обсуждения простран­
ства задач можно использовать ОГРА НИЧЕННЫЕ КОНТЕКСТЫ, но они однов­

ременно тесно связаны с пространством решений.
Пространство решений

-

это область, в которой фактически реали­

зуется решение, идентифицированное в результате анализа пространст­
ва задач как СМЫСЛОВОЕ ЯДРО

(CORE DOМAIN ) . СМЫСЛОВЫМ ЯДРОМ называ­

ется ОГ РАНИЧЕННЫЙ КОНТЕКСТ , который разрабатывается как ключевая
стратегическая инициатива организации. Решение в этом ОГРАНИЧЕННОМ
КОНТЕКСТЕ преобразуется в исходный код

-

основной и тестовый. Кроме

того, в пространстве решений разрабатывается код, поддерживающий ин­
теграцию с другими ОГРАНИЧЕННЫМИ КОНТЕКСТАМИ .

Глава

2. Стратегическое проектирование с помощью Ограниченных ...

Ограниченный контекст

Программная модель. функционирующая в ОГРАНИУЕННОМ КОНТЕКСТ Е.
отражает язык. на котором говорят все ее разработчики. Этот язык назы­
вается ЕДИНЫМ ЯЗЫКОМ . потому что он используется как Д1IЯ общения в груп­

пе разработчиков. так и Д1IЯ реализации модели. Таким образом. ЕД И НЫЙ
ЯЗЫК должен быть формальным

-

строгим. точным. конкретным и вырази­

тельным. На диarрамме прямоугольники внутри ОГРАНИЧЕННОГО КОНТЕКСТА

представляют концепции модели. которые могут быть реализованы в виде

классов. Если ОГРАН ИУ ЕНН ЫЙ КО НТЕ КСТ разрабатывается как ключевая стра­
тегическая инициатива организации. она называется СМЫСЛОВЫМ ЯДРОМ .

По сравнению со всем программным обеспечением. которое использу­

ет ваша организация. СМЫСЛО В О Е ЯДРО представляет собой самую важную
программную модель. потому что именно оно должно принести организа­

ции конкурентное преимущество. СМЫСЛОВО Е ЯДРО разрабатывается так.

чтобы ваша организация могла конкурировать со всеми остальными ком­
паниями. Оно должно решать хотя бы основные проблемы вашего бизнеса.
Ваша организация не может превосходить всех и во всем. можете даже не
пытаться. Следовательно. необходимо тщательно обдумать. каким должно

быть СМЫСЛОВОЕ ЯДРО и каким оно не должно быть. Это первое ценностное
преД1Iожение ООО. позволяющее организации правильно выбрать СМЫСЛО ­
ВОЕ ЯДРО и выделить Д1IЯ него лучшие ресурсы.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Когда какой-нибудь член группы использует выражени е Е ДИН О ГО Я ЗЫКА ,
все

остальные

члены

группы

должны

совершенно

точно

понимать

его

смысл. Это выражение должно быть широко распространенным в пределах

группы. как и весь язык. определяющий разрабатываемую программную
модель.

Размышляя о языке программной модели. вспомните о разных народах.
населяющих Европу. В каждой из европейских стран существует офици­
альный язык. на котором говорят все ее жители. Наприме р. в германии.
Франции и Италии официальные языки определены точно. Когда вы пе­

ресекаете границу. официальный язык изменяется. То же самое каса­
ется Азии. где в Японии говорят на японском языке. а языки. на которых
говорят в Китае и Корее. четко ограничены национальными границами.

О ГРАНИЧЕННЫЕ КО НТЕК С ТЫ можно сравнить с языковыми границами. В слу­

чае ООО речь идет о языках. на которых говорят члены группы разработ~

чиков программнои модели. а также о языках программирования. на кото~

рых написан ее исходныи код.

,

Рта

=

Ограниченные контексты, группы
и репозитории исходных текстов
Над каждым О ГРАНИЧЕННЫМ КО Н Т Е КСТОМ должна работать только одна
группа. Кроме того, каждый О ГРАНИЧЕННЫЙ КО НТЕК СТ должен иметь от­
дельный репозиторий исходного кода. Одна группа может работать над
несколькими О ГРАНИЧЕННЫМИ КО НТЕК С ТАМИ, но над одним О ГРА Н И ЧЕНН ЫМ



Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

КО НТЕКСТ ОМ не должны работать несколько групп. Четко отделите исход­
ный код и схему базы данных каждого ОГРАНИЧЕ НН ОГО КО Н ТЕКСТА так
же, как вы отделяете ЕДИ НЫ Й ЯЗЫК контекста от остальных контекстов.
Храните прием очные тесты и тестовые модули вместе с основными исход­
ными кодами.

Еще раз подчеркнем очень важное требование, что одна группа долж­
на работать только над одним О ГРАНИЧЕННЫМ КОНТЕКСТОМ . Это полно­
стью

устраняет

возможности

могут возникнуть,

когда другая

любых

неприятных

сюрпризов,

группа вносит изменения

в ваш

которые


исходныи

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

ваш ОГ РАНИЧЕННЫЙ КО НТЕКСТ . В этом заключается одно из преимуществ

использования ООО.

Ограниченный контекст

- ........
Единыйязык

I

---------------------,

1,..--_ _
I

:'--I
I

Вне контекста

I
I
I
I
I
I
I

,---------------------,
В естественных языках терминология развивается в течение долгого
времени. и в разных странах одни и те же или похожие слова имеют раз­

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

Очевидно, что существуют испанский язык И спан ии и испанский язык

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

мину разные значения, потому что их бизнес-знания относятся к разным

контекстам; они разрабатывают разные ОГРАНИЧЕННЫЕ КО НТЕКСТЫ . Любые
компоненты вне контекста могут не описываться теми же определениями.

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

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Для того чтобы понять одну весомую причину использования ОГРАНИ ­
ЧЕ ННЫХ КОН Т ЕКС Т ОВ . рассмотрим типичную проблему прое ктирования про ­

граммного обеспечения. Часто группы не знают. когда следует прекратить
накапливать все новые и новые концепции в своей модели предметной об­

ласти. В начале модель может быть маленькой и управляемой ...

L

:r

L,

.:l. -...

~

~

Z

10<

71\\

~
~

\

~

L
Но затем группа добавляет в модель все больше и больше концепций.
Вскоре это приводит к большой проблеме. Мало того. что появляется слиш-

-

ком много концепции. но и язык модели становится нечетким. потому что.
когда вы думаете о нем. то на самом деле используете н е сколько языков в

одной большой и запутанной модели.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Из-за ЭТОЙ ошибки группы часто преврэщают новое программное изделие
в то. что называют БОЛЬШИМ комом ГРЯЗИ (ВI G

BALL OF мио).

Безусловно. БОЛЬ ­

ШОЙ ком ГРЯ ЗИ не может быть предметом гордости. это монолит. И даже еще
хуже. Он представляет собой систему. состоящую из многочисленных запу­

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

ко разных команд. что очень проблематично. Кроме того, разные независи­
мые концепции разбросаны по многочисленныIM модулям модулей и взаимос­
вязаны с КОНфЛИК'1)'lOщими элементами. Если в таком проекте предусмотрено
тестирование. то оно может занять очень много времени. и поэтому тестами

MOryт пренебречь именно тогда. когда они на самом деле необходимы.

БОЛЬШОЙ ком ГРЯЗИ -

это результат попытки сделать слишком много. со

слишком многими людьми и в неправильном месте. Любая попытка раз­

работать и использовать ЕДИНЫЙ Я ЗЫК приведет к ломаному и плохо опре­
деленному диалекту. от которого вскоре все будут вынуждены отказаться.

Этот язык не будет похож даже на эсперанто. Это просто смесь. как БОЛЬШОЙ
ком ГРЯЗИ .

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Эксперты проблемной области
и бизнес-факторы
Иногда прямы е подсказки или тонкие намеки бизнес-партнеров позво ­
ляют техническим специалистам принимать более правильные решения.
Таким образом. БОЛЬШОЙ КОМ Г РЯ З И часто является результатом стихийных
усилий. предпринятых группой разработчиков программного обеспечения.
которые не слушают бизнес-экспертов.

Заключение договора
Политика

. -~


.

#" .tj '

''' &\ ''. J, ~.

....

4:I

...-.,-''-.
:<'

Инспекции
Претензии

Политика

Политика
и'

... ~J~.



.•.""

-; ...

~

~;

.

" ,е'

..

.

• ~ ... ~OCI

.~

.~'



Подсказать. где проходят границы модели. может разделение организа-

ции на отделы или рабочие группы. Обычно всегда можно найти хотя бы
одного бизнес-эксперта по конкретной бизнес-функции. В последнее вре­

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

иерархию управления. становятся все менее популярными. Даже столк­
нувшись с новыми бизнес-моделями. вы все еще будете обнаруживать. что

проекты организованы в соответствии с бизнес-факторами и в границах
областей знания. Возможно. о разделении функций следует думать именно
в этих терминах.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Тако е раздел ени е н еобходимо. когда анализ показ ывает. что каждая биз ­
н ес -функция может ис пользовать разны е определе ния одного и того же
те рмина. Разб е ре м ко нцепцию rюлитика и пос мотрим . как и з ме ня ется ее
зн а че ние в раз ных областях страхового дел а . Ле гко понять. что те рмин по­
литика при

подпи с ании

с трахового до говора

с ов е рш е нно

отлич ается

от

пол итики уре гул ирования претензий или ин с пе ктирования . Более подр об-

-

н о э ти р азл ичия о пи с аны во вр ез ке . прив еде ннои ниж е .

Те рмин политика в каждой из этих обл асте й им еет разный с мы сл . Этот
факт нел ьзя игнорировать или из ме нить путем умственных упражне ний.

Различия в толковании термина политика



Политика заключения страхового договора. В области знаний, связанной
с заключением страховых договоров,

политика означает правила оценки

рисков, которым подвергается предмет страхования . Например, работая
над договором страхования, страховщики должны оценить риски, связан­

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

Политика инспектирования . Страховые компании всегда имеют подраз­
деление инспекторов, проверяющих состояние предметов страхования.

Страховщики в не которой степени зависят от информации, обнаруженной
в ходе проверок, но только с той точки зрения, что состояние предмета
страхования

должно

соответствовать

условиям,

указанным

в

договоре

страхования. Если условия договора выполнены, то детали проверки
фотографии и описания

-

относятся к политике инспектирования. На эти

-

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

альной стоимости.

Политика

урегулирования претензий .

Политика урегулирования

пре ­

тензий регламентирует процесс рассмотрения претензии на возмещение
убытков в терминах политики заключения страховых договоров. Политика

-

урегулирования претензии должна ссылаться на правила заключения стра-

ховых договоров, но в основном она сфокусирована на оценке поврежде-

-

нии предмета страхования и результатах осмотров, выполненных персона-

лом в соответствии с процедурами, чтобы определить размер выплат, если

их вообще следует делать.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

I,

I

Политика



,

~.

,

-

Заключение договора
Претензии
Инспекции

"

~



,

-






• "• •

Если вы попробуете объединить все три вида политики в одну полити­
ку для всех трех бизнес-групп. то. конечно. столкнетесь с проблемами. Это
стало бы еще более проблематичным. если термин политика впоследствии
будет перегружен четве ртым и пятым толкованиями. Все окажутся в про­
игрыше.

,

I Политика

I

Контекст подписания
договоров



--

.

I Политика

,

1

Iг-п-о-л-ити-ка
.....

Контекст инспектирования

" Контекст
" урегУлирования
.

,

претензий "

I'

"

'



С другой стороны. ООО подчеркивает такие различия с помощью разде ­
ления разных типов по разным ОГРАНИЧЕННЫМ КОНТЕКСТАМ . При этом счита ­
ется. что каждый контекст имеет свой язык и соответственно функциони­
рует. Существуют три толкования термина политика? Значит. существуют

три ОГРАНИЧЕН НЫХ КО НТЕКСТА . каждый со своей собственной политикой.
имеющей уникальные особенности. Нет никакой потребности называть их

UnderwritingPolicy. ClaimsPoli cy

или

InspectionsPolicy.

Область их

видимости определяется именем соответствующего ОГРА НИЧЕНН ОГО КОН ­

ТЕКСТА . Назовите эту концепцию просто
КОНТЕКСТАХ .

Policy

во всех трех ОГРАНИЧ ЕННЫХ

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Другой пример: что такое полет?
в отрасли авиаперевозок термин полет

(flight)

может иметь несколько зна­

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

другой вид полета, определяемый в терминах, связанных с обслуживани­
ем самолета. И есть еще один полет, определенный в терминах, связанных
с покупкой билетов пассажирами,

беспосадочный или с пересадкой.

-

Поскольку каждое из этих толкований термина полет становится ясным
только в его контексте, каждое из них должно моделироваться в отдель-

.

ном ОГРАНИЧЕ Н НОМ КОН Т ЕКС ТЕ . Моделирование всех трех терминов в од­
ном и том же ОГРАНИЧЕ Н НОМ КО Н ТЕКСТЕ привело бы к путанице .

Product

$prlnt

S_d u IedВocl<log I t"",

T08k

CommittedВocl<IogI tem

Е 8unюt oon LogЕ n tr у

Типичный пример
Для того чтобы пол нее разъя снить причины и с п ользов ания ОГРАНИ ­
ЧЕННЫХ КОНТ Е КСТОВ . позвольте мне про иллюстриро вать их н а приме ре од­

н о й пр едметной области . Представим себе прое кт. р аз рабатывае мый на
ос н о ве методоло гии гибко го пр ое ктиро вания

ти е м явля ется Продукт

{Pr oduct)t -

Scrum.

Его о с но вным п о ня­

программно е обес пе че ние. которое

должно быть со здано и впоследствии усо верш е нствован о . По няти е Продукт

подразделяется на Элементы бэклога
Спринты

(Sprint).

(Bac klogItem). Выпуски (Release ) и

Каждый Элемент бэклога с о стоит из множеств а Задач

(Task). каждая из которых может им еть колле кцию Записей журнала оценок
(EstimationLogEntry). Выпуски соде ржат Запланированные элементы журна­
ла невыполненных работ (ScheduledBacklog I tems ). а Спринты - Назначенные
1 В с кобках указаны име н а соответствую щих кл ассо в . прив еде нных н а диа гра м ­

ме.

-

При ме ч . ред.

Глава

элементы бэклога

2. Стратегическое проектирование с помощью Ограниченных ...

(CommittedBacklogItem).

Пока неплохо. Мы идентифици­

ровали основные понятия нашей модели предметной области. а язык точен
и прозрачен.

Produc'
тei"'lont

Dtасussюn
В<> cl< IogJ'e",

u•.,

Sprtnt

R&leose

CommlttedВoc.klog ltem

T08k

Е а"",оtюnL ogЕntrу

"О. да

-

зователях.

говорят члены группы.

-

давайте не забывать о наших поль­

Мы хотим облегчить совместные обсуждения в группе раз­

работчиков продукта.

Давайте представлять каждую организацию-под­

писчика как Арендатора

(Tenant).

Внутри Арендатора мы позволим реги­

страцию любого количества Пользователей

(User).

которые будут иметь

Полномочия

(Permi ssion). Кроме того. давайте добавим понятие Обсуждение
(Discussion). чтобы представить инструменты взаимодействия. которые
мы поддерживаем".
Producl
F",um

Tenont

8ockloQltetn
~.с:u.sюn

Col«Idot Entry

CQmIТ'II! ted8oc:k)og i 1.."

Tosk

РО&,

Е stll\'lO!:юnl..ogЕntry

Затем члены группы добавляют: "Хорошо. но сушествуют и другие ин­

струменты взаимодействия. Обсуждения можно вести на Форумах
кроме того. Обсуждения связаны с Сообщениями
поддержать Общие календари

(SharedCalendar)".

(Post ).

(Forum).

Также мы хотим

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

F'rodvc. t

Т"""'"

DI$Gu,мon

CoI.rIcsarEnlry

Ро"

Они продолжают: "И не забывайте. что нам нужен способ. которым
. Арендаторы будут делать Платежи

(Payment ).

Мы также предлагаем гиб­

кие планы поддержки. поэтому нам нужен способ слежения за процессом
поддержки. И Поддержка. и Платежи должны управляться Учетной записью

(Account )".
P«><lu<'

Co!.ndorEntr)'

TOik
IntlOofnt

ProducctO WtI@I"

Со временем появляется все больше концепций: "Каждый Продукт. раз­

рабатываемый на основе методологии

Scrum.

имеет конкретную Группу

( Т е аm). которая воздействует на Продукт. Группы состоят из одного Владельца
Продукта

(ProductOwner)

и множества Членов Группы

(TeamMember).

Но как

учесть вопросы. свлзанные с использованием человеческих ресурсов? Что.

если мы смоделируем Графики работы членов группы
фективностью их работы и доступностью?"

(Schedule) вместе с

эф­

2. Стратегическое проектирование с помощью Ограниченных ...

Глава

'......

"'-,

L
50.: ~ • tPIOr>

.J!:

....-,

L,

...

R • .-

iar.IolDQ lt.on

и_

"'-

~

~

Т'"

Sd"~ l t_

"OOU<:lo-...

~

~

1....:

T~:\\
~

T...,.~
1Ч1 ,

--

__

T~IO(IW

\~

.........

T~tRмourц

:z

5d 1 ~_


-

~Enll',

.........

~

f.'~oofnlfJ

"Знаете что?

...,

Co-m.t~ ; I_

,-

...-

с_

o..CU.8.on

.J

"'-

1r.c: ,d8t\1

,,-,
.:L

говорят члены группы.

-

Q '~ ..

ty

Общие Календари не должны ог­

раничиваться пустыми Календарными записями

(CalendarEntry).

Мы долж­

ны иметь возможность идентифицировать конкретные виды Календарных
записей

вроде Напоминаний

(Reminder), Контрольных сроков (Milestone).
Запланированных встреч (Planning) и Состоявшихся встреч (Retrospecti ve).
а также Расчетных сроков (TargetDat e)".
Остановитесь на минуту! Вы видите западню. в которую попала эта
группа? Посмотрите. как далеко они отклонились от первичных основных

концепций Продукт. Элементы бэклога. Выпуски и Спринты. Язык больше не
описывает только методологию

Scrum;

он стал запутанным и непонятным.

I

;1
I

L

I

I

Не заблуждайтес ь относительно небольшого количества именованных

концепций. За каждым именованным элементом скрываются две или три
связанных с ними концепции.

которые немедленно всплывают в памяти.

Группа уже дал е ко продвинулась к поставке БОЛЬШОГО КОМА ГРЯЗИ . хотя про­
ект е ще только начался.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Ограниченный контекст

.

....-г-

ЕДиныйязык

Необходимость фундаментального
стратегического проектирования
Какие инструменты ООО позволяют избежать описанных выше лову­

шек? Для этого нужны по крайней мере два инструмента фундаменталь­
ного стратегического проектирования. Первый

второй

-

-

ОГРАНИЧЕННЫЙ КОНТЕКСТ ,

ЕДИНЫЙ ЯЗЫК . Использование ОГРАНИЧЕННОГО КОНТЕКСТА заставля­

ет нас ответить на вопрос: "Что является ядром?" ОГРАНИЧЕННЫЙ КОНТЕКСТ
должен объединять близкие концепции, которые являются ядром страте­
гической инициативы, и отбросить все остальное. Оставшиеся конце пции
являются частью ЕДИНОГО ЯЗЫКА группы. В дальнейшем мы покажем, как

подход ООО позволяет избежать создания монолитных приложений.

Проверка преимуществ
Поскольку ОГРАНИЧЕННЫЕ КОНТЕКСТЫ не монолитны, их использование
приносит дополнительные преимущества. Одно из них состоит в том, что
тесты сосредоточиваются на одной модели, а значит, их количество умень­

шается и они выполняются быстрее. Хотя это не главное преимущество
ОГРАНИЧЕННЫХ КОНТЕКСТОВ , оно окупается во многих ситуациях.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Ограниченный контекст



Внутри контекста...

IЪворя буквально. некоторые концепции окажутся в контексте и будут
явно включены в язык группы.

Ограниченный контекст

1

Внутри контекста...

.



Вне контекста ...

Другие концепции будут находиться вне контекста. Концепции. которые
пройдут строгий отбор для включения в ядро. станут частью ЕДИН О Г О ЯЗЫКА
группы. которая владеет О ГРАНИЧЕННЫМ КОНТЕКСТ ОМ .


Примите к сведению
Концепции, прошедшие строгий отбор ДЛЯ включения в ядро, являются

частью ЕДИНОГО языКА группы, владеющей ОГРАНИЧЕННЫМ КОНТЕКСТОМ .
Граница подчеркивает строгий порядок внутри контекста.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Разработчики

Эксперты предметной области

Так что же такое ядро? Это область. в которой мы должны объединить


v

две группы люде и в единую команду соратников

-

v

экспертов предметнои

области и разработчиков программного обеспечения.

Продукт
Группа

Элемент бэклога

Выпуск Задача

Владелец продукта

Спринт

ВОЛ9 нтер

[J е
..1

<ь

..ос!о ....
Q

D

~

о
L.

со

., "

'v

~ ..s>

ot:lc

u

С"

о{:)
OJI

Q

О

ы

') <

"

Мысли ЭКСПЕРТО В ПРЕДМ ЕТНОЙ ОБЛАСТИ . естественно. будут больше сос­
редоточены на вопросах бизнеса: в центре внимания будет их представле­
ние о том. как работает их бизнес. В методологии

Scrum

ЭКС ПЕ РТ ПРЕДМ ЕТ ­

НОЙ ОБЛАСТИ играет роль Scrum-мастера. который полностью понимает. как

Scrum прим е няется к проекту .
... ,.

.ре

ПРОДУКТА ИЛИ

ЭКСПЕРТ ПРЕДМЕТНОЙ ОБЛАСТИ?
Вы можете задаться вопросом, в чем различие между ВЛАДЕЛ ЬЦ Е М ПРО ­

ДУКТА

Scrum и ЭКСП Е РТОМ ПРЕДМЕТ Н ОЙ ОБЛАСТИ DDD. В некоторых случа­

ях эти роли может играть один и тот же человек, способный их выполнить.
И все же не следует удивляться тому, что ВЛАДЕЛЕЦ ПРОД УКТА обычно
сильнее сосредоточивается на управлении и распределении приоритетов

в бэклоге продукта, стремясь поддерживать концептуальную и техниче­

скую целостность проекта. Однако это не означает, что ВЛАДЕЛЕЦ ПРО ­
ДУКТА естественным образом является ЭКСПЕРТОМ ПРЕДМ Е ТНОЙ ОБЛАСТИ,
над которой вы работаете. Включайте в группу только настоящих ЭКСПЕР -

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

,

ТОВ ПРЕДМЕТ Н ОИ ОБЛАСТИ и не заменяете их ВЛАдЕЛЬЦАМИ ПРОДУКТА, не

владеющими необходимым ноу-хау.

в вашем конкретном бизнесе также существуют ЭКСП Е РТЫ ПРЕДМЕТНОЙ
ОБЛАСТИ . Это не должность. а характеристика людей. которых главным
образом интересует предметная область. Именно их ментальная модель яв­
ляется отправной точкой для формирования ЕДИ Н ОГО ЯЗЫКА группы.

(а < Ь) { OxFВ249E7
а += с;
с# Scala Java

while

JavaScript РНР

}

ВРИ

10110001101010110001

с другой стороны.

BPEL

разработчики сосредоточены на разработке про ­

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

разработчики. работающие над проектом в рамках подхода

000,

должны

упорно сопротивляться соблазну зациклиться только на технических воu

u

u

пр осах и не вникать в деловои смысл основнои стратегическои инициати-

вы. Разработчики должны отклонять любую неуместную лаконичность и

быть в состоянии освоить ЕДИНЫЙ ЯЗЫК , который постепенно вырабатывает
их группа в конкретном ОГРАНИЧЕННОМ КОНТЕКСТЕ .

Сосредоточьтесь на сложности предметной
области, а не на технической сложности
Вы используете

DDD,

потому что сложность предметной области высока.

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

DDD, потому что модель

предметной области сложнее, чем технические аспекты проекта. Именно
поэтому разработчики должны вникнуть в модель предметной

вместе с ЭКСП Е РТАМИ ПРЕДМЕТНОЙ ОБЛАСТИ !

области

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

???
• • •

???
• • •

s•

.,,

и разработчики, и ЭКСПЕРТЫ ПРЕДМЕТНОЙ ОБЛАСТИ не должны допустить,

. чтобы

документы заменили живое общение. Лучший ЕДИНЫЙ ЯЗЫК можно

выработать только при наличии обратной связи, управляющей объединен­
ной ментальной моделью группы. Открытый разговор, исследование и обо­
гащение ваших знаний будут способствовать более глубокому пониманию
СМЫСЛОВОГО ЯДРА .

Ставьте проблемы и обобщайте
Вернемся к вопросу: что является ядром? Используя прежде неуправляе­
мую и постоянно расширяющуюся модель, ставьте проблемы и обобщайте!

Тenon\

Produ<;\

и.Of
Вocklog !1@m

To.k

ReIeo.e

S~logl t em

Е .lImotюn!. ogE ntr y

Есть одна очень простая проблема

-

выяснить, соответствует ли ка­

ждая из концепций крупной модели ЕДИ Н ОМУ ЯЗЫКУ

цепции Арендатор

(Tena n t ).

Пользователь

(User )

не имеют ничего общего с методологией

Scrum.

Например, кон­

и Полномочия

Scrum.

(Permission)

Эти концепции должны

быть исключены из нашего программного обеспечения.

Глава

2. Стратегическое проектирование с помощью Ограниченных ...

Product

О ls сu.sеюп

$prtnl

Sc/Ittdul.dВoclclogltem

T08k

Com,nltt..:i&cklogl,.m

__ ...-----~,-~- _:-:_~:::=::::;~":_~_::-:- - - I

I

ТtЮm

I
Е 8ttmotюnlog Е пtгу

1

••


I

:


,---"';

...;--



ProductOwnм

I ' -_ _ _. . 1,._ _ __


,---------------,

Концепции Арендатор. Пользователь и Полномочия
быть заменены концепциями Группа ( Теаm).

Owne r )

и Член группы

(TeamMember).

(Permission) должны
Владелец продукта (Pr oduct -

Концепции Владелец продукта и Член

группы фактически представляют собой концепцию Пользователь внутри
концепции Аренда ( Тепапсу). но Владелец продукта и Член группы

мины ЕДИН ОГО ЯЗЫКА

Scrum.

-

это тер­

Это естественные термины. которые мы ис­

пользуем. говоря о Sсгum-проДУКтах и работе группы. которая их разраба­
тывает.

Product

Вocl<logl,om

Tosk

S<:heduIedВocl<Iog l tem

Cofn",'!! t t.o9ockl09 1ttnТt

Incidont

E.timotoonlogEn'rj'
ProouctOwn+f"

Являются ли Планы поддержки

управления проектами

Scrum?

(Suppo rtPlan) и

Ответ очевиден

-

Платежи

нет. Правда. Планы под­

держки и Платежи будут управляться Учетной записью
но они не являются частью основного языка
контекста и должны быть удалены из модели.

(Payment ) часть ю

(Account )

Scrum.

Арендатора.

Они находятся вн е

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

Product

Вocklogltem

Tosk

A~M

Spnnt

ScheduledВocklogltem

Committ...:!Вockloglt.....

T.om
Е sUm<:!tюnLogЕntrу

ProductOw"..,.

Resоurс.моnog"
т lfТI@Consum,ngR",ource

Sch.dul ..

......Iob'bty

Не следует ли нам ввести концепции управления человеческими ре­

сурсами? Эти концепции, вероятно, для кого-нибудь могут оказаться по­

лезными, но они не будут непосредственно использоваться Волонтерами

(Voluntee r ), представляющими собой разновидность Членов группы ( Теаm ­
Member), которые будут работать над Задачами, связанными с элементами бэ­
клога (BacklogltemTasks). Они находятся вне контекста.

Глава

2.

Стратегическое проектирование с помощью Ограниченных ...

_1
ReI8ca••

Sprinl

T08I<
г'

,,,

-

-

г----'

'--

,'--------_ ....

,,
,

т..""

E'~ooEntry

ProductOwn.r

TeomМIi,1b«

После добавления концепций Группа. Владелец продукта и Член группы
разработчики модели поняли. что они пропустили основную концепцию,
позволяющую Членам группы работать над Задачами. В методологии

эта концепция называется Волонтер

(Vol un tee r).

Scrum

Следовательно, концеп­

ция Волонтер находится в контексте и должна быть включена в язык основv

нои модели.

......
C ~ t . rмSorEnlJy

.....

f _timocJonL ogfntry

,ом

ProductOWNW

Несмотря на то что концепции Контрольный срок

шаяся встреча

(Retrospec t i ve) и

(Milestone),

Состояв­

им подобные находятся в контексте, груп­

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

Глава

2. Стратегическое проектирование с помощью Ограниченных ...

Produ<:t

-----1.----- 1
1
I

Sprint

1

Or.CU881On

1

I

1

,------'

То '"

Т...",

е а timotюnl ogеf't,у

P,odUGtO_

Наконец,
Обсуждения

разработчики

(Discussion)

TeomМemb«

модели хотят удостовериться,

что те кущие

будут частью основной модели. В р езул ьтате они

моделируют Обсуждение . Это означает. что Обсуждение явля ется частью
ЕДИН О ГО ЯЗЫКА группы, а значит, находится в ОГРАНИЧЕННОМ КОНТЕКСТЕ .

,

,

Product



CoI.ndarEntry







,

Эти лингвистические пробле мы сделали ос новную модель и модель ЕДИ ­
Н ОГО ЯЗЫКА более я сными. И все же, как будет модель

Scrum

о существлять

необходимы е Обсуждения? Для этого, конечно, потребуется большое коли­
чество вспомогательного программного обеспечения. Таким образом , м о­

делиро вать Обсуждения в О ГРАНИЧЕННОМ КОНТЕКСТЕ Scгum не целесообр аз­
но. Фактичес ки вес ь набор концепций Сотрудничество находится вне кон­

текста. Обсуждение будет поддерживаться путем интегрирования с другим
ОГРАНИЧЕННЫМ КОНТЕКСТОМ -

Контекстом Сотрудничества .


Related documents


PDF Document     agile
PDF Document tcu11 ppt ch08 backup
PDF Document tcu11 ppt ch08a
PDF Document untitled pdf document 3
PDF Document chap4 b
PDF Document chap3


Related keywords