Статья "Проектирование больших информационных систем в Agile" к одноименной презентации. Специально для конференции SECR-2009

1. How to Design Large Scale Systems in Agile
Bibichev Andrey
Customized InformSystems Ltd. (CustIS)
andrew@custis.ru
Abstract (English)
Can Agile fit to a project of creating large scale enterprise system? Is it possible to tame the complexity and not
to allow it to grow exponentially? How to arrange the process of designing the system without violating the
principles and spirit of Agile?
The article gives an overview of modern approaches to design: Model-Driven Design (MDD), Domain-Driven
Design (DDD), Feature-Driven Development (FDD). A common seed is extracted from them – the domain
model.
Practical tips are given for creating domain models and using them in development of business logic. An
example of creating such a model is presented.
The final part deals with issues related directly to the organization of the design process. The most frequent
mistakes are listed that lie in the way of designers and developers following the DDD.
The material has introductory nature and does not require technical skills.
Keywords: domain model; DDD; FDD; UML; Agile.
Проектирование больших ИС в Agile
Бибичев Андрей
ООО «Заказные ИнформСистемы» (CustIS)
andrew@custis.ru
Abstract (Russian)
Можно ли работать над проектом создания большой информационной системы корпоративного
уровня по Agile-методологии? Можно ли обуздать сложность и не дать ей экспоненциально расти?
Как правильно подойти к проектированию, не нарушив принципов и духа Agile?
В статье обзорно рассматриваются современные подходы к проектированию и дизайну: Model-
Driven Design (MDD), Domain-Driven Design (DDD), Feature-Driven Development (FDD). Из них
выделяется общее зерно – модель предметной области (domain model).
Даются практические советы по созданию моделей предметных областей, их использованию при
написании бизнес-логики. Приводится пример создания такой модели.
В заключительной части разбираются вопросы, связанные непосредственно с организацией
процесса проектирования. Разбираются наиболее частые ошибки, которые подстерегают и
проектировщиков, и разработчиков на пути следования DDD.
Материал носит обзорно-вводный характер и не требует специальных технических знаний.
Ключевые слова: модель предметной области; DDD; FDD; UML; гибкие методологии; Agile.

2. 1. Введение Так как же быть в подобных ситуациях? Как
преодолеть эскалацию сложности? В чем «секрет
молодости» больших проектов?
Agile популярен, Agile повсеместно
Многие вспоминают об Унифицированном
внедряется, все переходят на Agile. Но как только
Процессе (Unified Process, UP). Но он такой
команда осваивает базовые вещи – итерации,
большой и такой унифицированный, что в нем
жесткие временные рамки (time-boxing),
легко заблудиться и не найти того инструмента,
эффективные коммуникации, командную работу
который вам поможет. Кроме того, хотелось бы
и совместные обязательства (commitment), –
остаться в рамках Agile-идеалов [1]:
возникает острое ощущение, что чего-то всѐ же
невысокая цена поздних внесений изменений
не хватает. И если проект небольшой (два-три
месяца работы команды из 4-7 человек), то, в начальные требования;
скорее всего, особых проблем не возникнет – вы максимальная вовлеченность самих
успеете сделать проект до того, как остро разработчиков в процесс проектирования и
осознаете, в чем же загвоздка. На проекте дизайна;
средних размеров (около полугода или даже года минималистичная документация (Agile-
работы типичной Agile-команды) уже можно спецификации и т.п.);
успеть испугаться, но за счет трудовых подвигов программный код, из которого легко понять
и неординарных личностей такие проекты тоже основные проектные решения.
чаще всего успешно выполняются.
А что делать с большими проектами (скажем, Данный материал посвящен именно этому
от 10-15 чел.лет)? Здесь без какого-то общего вопросу. Причем речь будет идти не о
проектирования и дизайна уже почти невозможно произвольных компьютерных системах, а об их
– простой инкрементальный подход приводит к enterprise-подмножестве, т.е. корпоративных ИС
экспоненциальному росту сложности внесения (ERP, CRM, биллинги, банковские, складские и
изменений, возникают ситуации из серии «в торговые системы и т.д.).
одном месте прилепили – в другом отвалилось».
Более того, разработка успешных систем не 2. xDD-зоопарк
заканчивается в момент ввода в боевую
эксплуатацию – такие системы развиваются Если в мире Agile попробовать поискать
дальше, причем, очень часто, силами других готовые рецепты и подходы, то вы обнаружите
команд. В таких условиях экстремально важно с массу трехбуквенных аббревиатур,
одной стороны сохранить качество и надежность заканчивающихся на «DD»:
решения, а с другой – не потерять темпы Test-Driven Development (TDD) [2];
развития, т.е. наращивания/модификации Feature-Driven Development (FDD) [3];
функциональности под растущие/меняющиеся Domain-Driven Design (DDD) [4];
потребности бизнеса. [Agile] Model-Driven Development/Design
В практике компании «Заказные (MDD) [5, 6];
ИнформСистемы» большинство проектов Agile-specification-Driven Development
именно такие: самые долгожители уже (AsDD) [7].
перевалили через десяток лет активного Распространена шутка, что все трехбуквенные
развития. Ниже на графике приведена динамика аббревиатуры давно заняты. Похоже, для Agile-
роста функциональности одной из таких систем тусовки зарезервировали *DD-сегмент .
(за начало отсчета взят момент ввода в боевую Дабы разобраться в этом нагромождении
эксплуатацию, а объем функциональности в этот аббревиатур, подойдем с другой стороны – от
момент – за 100%): конкретных Agile-методологий.
2.1. Scrum
Что предлагает наиболее популярная Agile-
методология [8] для решения задач
проектирования и дизайна ПО? Ответ простой:
ничего.
Scrum вообще не касается каких-либо
технических моментов. В связи с этим, данную
методологию очень часто дополняют
отдельными практиками из eXtreme Programming
(XP) – получается «XP driven by Scrum» [9].
Рис. 1. Темпы развития функциональности ИС

3. 2.2. XP компонуется итоговая, вбирая лучшие
решения из каждой;
Экстремальное программирование
в рамках итераций разрабатывается
пропагандирует инкрементальный дизайн, а отдельный кусочек модели, для чего он
спасаться предлагает при помощи таких практик, вначале уточняется и детализируется.
как разработка на основе тестов (TDD) и
рефакторинга (Refactoring – продвинутое
«причесывание» кода) [10].
Unit-тесты писать – это точно полезно (хотя до
сих пор далеко не все проектные команды
находят в себе силы обеспечивать приемлемое
покрытие кода автоматическими тестами, в
основном ссылаясь на нехватку времени). Писать
тесты до реализации (как того требуют буквы
TDD) может быть тоже оправданно с точки
зрения конструирования API, которым удобно
пользоваться (хотя, в этой роли такая вещь как
«мысленный эксперимент» тоже весьма не
дурна). Но можно ли спроектировать большую Рис. 2. Схема процесса в FDD
систему в виде заранее написанных unit-тестов,
да ещѐ, чтобы дизайн системы был из них Т.е. что мы видим: серьезный упор сделан на
понятен и легко извлекаем? Лично я таких центральную роль модели предметной области,
примеров не встречал. Кроме того, не понятно, широко используется UML, а в процесс
как можно уберечься от возрастания сложности разработки плотно встроены дизайн-сессии. Всѐ
внесения изменений при помощи тестов (можно очень похоже на Unified Process, только проще и
только понизить риск что-нибудь сломать). конкретнее.
Кстати, Agile-specification-Driven Development 2.4. OpenUP и AgileUP
есть не что иное, как помесь TDD и Design-By-
Contract. Т.е., опять же, ничего принципиально Прямые «наследники» Unified Process (UP). В
нового (по сравнению с TDD) не предлагает. рамках этих методологий подразумевается
Рефакторинг (Refactoring) – широко широкое использование как моделирования в
распространенная и популярная практика. Правда целом, так и UML в частности. В рамках UP
и здесь могут быть свои подводные камни и наибольшую популярность получили два
поведенческие анти-паттерны [11]. Как бы то ни подхода:
было, рефакторинг нацелен в первую очередь на 1. Model-Driven Design/Development
относительно локальные улучшения, а чтобы (разработка на основе модели);
исправить серьезные ошибки или недостатки 2. Model-Driven Architecture (архитектура на
общего проектирования, придется прибегать к основе модели).
реинжинирингу, что уже и тяжело, и рискованно, По большому счету, одно от другого
и долго. отличается только акцентами – и там, и там
Т.е. перечисленные практики могут помочь в ключевую роль играет модель [12]. Просто в
создании отдельного компонента, но как быть в случае Model-Driven Architecture
целом с большой системой так и остается программированию отводится второстепенная
неясным. роль – в идеале автоматическая кодогенерация по
подробным и точным UML-диаграммам
2.3. FDD (использование UML, как языка
К сожалению, Feature-Driven Development программирования). Надо отметить, что такой
(FDD) не так подробно описана в литературе. подход (автоматическая кодогенерация на основе
Этой методологии посвящена всего одна глава в диаграмм) показал свою серьезную
[3]. Что из нее можно почерпнуть: ограниченность на практике: сил на создание и
поддержание столь подробных моделей уходит
FDD нацелена на большие проекты
больше, чем на написание кода, а сами модели
(изначально применена при создании
серьезной банковской системы); становятся сильно утяжеленными,
перегруженными и малопонятными.
в процессе выделяется начальный этап
проектирования – моделирование 2.5. The last but not the least
предметной области при помощи UML;
Итак, из упомянутого семейства xDD, остался
причем создается несколько
только Domain-Driven Design (DDD), т.е. дизайн
«конкурирующих» моделей (независимыми
на основе модели предметной области.
командами), а затем совместными усилиями

4. Этот подход не связан напрямую ни с одним Единственно, когда речь идет о предметной
из процессов, хотя возник именно в Agile- области и бизнес-логике, принято использовать
сообществе. Грубо говоря, это Agile-наследник несколько уточненную терминологию:
MDD с уклоном в вопросы реализуемости сущность (entity) – объект предметной
модели предметной области в программном коде. области, обладающий уникальной
Сейчас тема DDD очень популярна и по- идентификацией (identity);
прежнему остается проблемной. Эрик Ивенс (Eric атрибут (attribute) сущности – свойство
Evans – автор DDD) в одном из интервью сетует объекта предметной области, выраженное в
на широкое распространение неверных трактовок виде значения простого типа (число/дата/т.д.)
и заблуждений [13]: «One thing that excites me is или связи с другой сущностью;
when people take the principles I talked about in my действие (action) над сущностью – в
book and use them in ways I never expected». программном коде выражается методом
Так что обязательно прочтите книгу Эрика [4], класса сущности.
чтобы не впасть под влияние горе-трактователей.
Кроме того, на InfoQ есть краткое введение в 3.2. Использование UML
DDD [14], которое можно скачать бесплатно. В качестве графической нотации традиционно
используют UML в режиме эскизного
Изложенный ниже материал опирается на моделирования [15]. Он не самым лучшим
сочетание FDD, MDD и DDD, причем по духу и образом подходит для этих целей, но ничего
смыслу ближе всего именно к DDD. лучше до сих пор не придумали. Если вам
кажется, что какой-то нестандартный
3. Модель предметной области рисунок/чертежик ярче и четче отражает тот или
иной аспект модели – не смущайтесь и
Итак, и в FDD, и в MDD, и в DDD используйте его (здесь нет догмата).
центральную роль играет модель предметной UML предлагает целый набор различных
области (domain model). Что это и как это? видов диаграмм. При моделировании предметной
Модель предметной области, как и любая области чаще всего прибегают к помощи
другая модель, является упрощенным диаграмм классов. Кроме того, мы (и не только
приближением реальности. Модель должна быть мы) активно используем диаграммы состояний (в
максимально простой при условии, что она в особенности там, где есть документооборот).
достаточной степени близка к действительности. Диаграммы деятельности и диаграммы
Мера достаточности – полезность создаваемой последовательности тоже применяются, но
информационной системы. Если модель будет весьма умеренно.
слишком простой, система будет почти Нравится кому-то UML или нет – это не так
бесполезна (не будет удовлетворять и малой важно, так как на данный момент это стандарт
толики реальных бизнес-потребностей). И не де-факто.
следует путать простоту и примитивность!
3.3. Пример: система продажи билетов
3.1. ООП на самолет
Физики в своих моделях используют Как происходит моделирование? А очень
математический аппарат плюс графические просто: вы (как человек, нечуждый разработке)
схемы (будь то изображение механической интервьюируете эксперта в предметной области и
системы или диаграммы Фейнмана). В IT-же для попутно пытаетесь зарисовывать его слова в виде
моделирования уже последние лет 20 принято диаграмм, делая дополнительные заметки.
придерживаться объектно-ориентированного Кстати, подавляющее большинство людей из
подхода (ООП) [18]. бизнеса быстро «схватывают» азы нотации и
Соответственно, и при моделировании начинают читать и верифицировать
предметной области имеет смысл мыслить в нарисованные модели.
терминах объектов, их связей, свойств и методов. Например, пусть нас попросили сделать
Это дважды выгодно: во-первых, накоплен систему продажи авиабилетов. Мы
большой опыт объектно-ориентированного разговариваем с экспертом в предметной
проектирования и мышления; а во-вторых, области 1.
современные языки являются объектно- Эксперт: Есть аэропорты. Для каждого
ориентированными, так что будет проще в известны название на местом языке,
реализации построенной модели (а это крайне
важно – см. ниже). 1
Диалог сильно упрощен. В жизни рассказывают и о
выполняемых действиях и операциях, а не только структуре
информации. Но на самом деле это не сильно меняет суть
происходящего.

5. уникальный латинский код и GPS-
координаты. Не стесняйтесь рисунков от руки – это же
Мы: эскизное моделирование! И не пытайтесь
уместить на диаграмме все детали, атрибуты и
связи – фиксируйте только важное/основное.
3.4. Словарь терминов
Отличное свойство такой модели: это
готовый словарь терминов. Дальше остается
Рис. 3. Сущность «Аэропорт» и её атрибуты договориться, что везде (и на интерфейсе, и в
программном коде, и в пользовательской
Эксперт: Аэропорты расположены в документации, и во всех обсуждениях) вы
городах. Для каждого города известно его используете исключительно термины, указанные
название (на местном и англ. языках). в модели.
Причем известно расстояние от аэропорта до Отлично работает! Не нужно составлять
центра города, к которому он «приписан». отдельный глоссарий (если только от вас этого не
Мы: требуют особые обстоятельства или дотошный
заказчик).
На практике не раз видел, как термины,
подобранные во время совместных сессий
моделирования, затем приживались и активно
использовались в бизнес-среде заказчика.
3.5. Несколько моделей
Не надо думать, что есть одна единственная
«правильная» модель. Нет. Моделей множество:
Рис. 4. Сущность «Город» и её связь с во-первых, многое зависит от вашего опыта и
«Аэропорт» пристрастий к тем или иным шаблонным
решениям;
Эксперт: Для каждого города есть
информация о стране, в которой он во-вторых, обязательно есть некий контекст,
в котором разрабатывается модель (в
находится.
приведенном выше примере это был
Мы:
контекст покупки авиабилетов, а если бы мы
делали систему регистрации пассажиров на
рейс, то модель была бы другой, так как там
важны и переносы рейсов, и объединение, и
расположение мест в самолете и т.д.).
Не стоит переживать по этому поводу. Это
можно использовать даже во благо: например,
как в FDD, создайте несколько
«конкурирующих» моделей, а затем «столкните
Рис. 5. Добавляется сущность «Страна» их лбами» и получите итоговую.
И так далее… В результате (пофантазируйте 3.6. История из личного опыта
на тему рассказа эксперта сами): Первый большой проект, который довелось
мне делать сразу в позиции team lead-а (ну или
вроде того), был связан с разработкой расчетно-
платежной системы для сферы коммунальных
услуг. Действовали по «доморощенной»
методологии, близкой к водопаду: когда проект
дошел до стадии разработки и меня подключили
к нему (вместе с группой разработчиков), уже
было написано большое техническое задание.
Так вот, из всего этого огромного документа
единственное, что мы использовали для
разработки, была диаграмма классов (опять же, в
«доморощенной» нотации), на которой была
изображена предлагаемая модель предметной
Рис. 6. Эскиз модели предметной области области.

6. Вот небольшой кусочек из этой модели (без Модель предметной области действительно
искажений, в оригинальной нотации: должна быть центральным элементом в вашем
означает связь «*-к- – связь «*-к- процессе разработки. Именно на еѐ основании
0..1»): должны создаваться и структуры хранения
данных, и программный код бизнес-логики, и
даже дизайн GUI.
Рис. 7. Фрагмент модели для расчета услуг ЖКХ
Модель была хорошей (еѐ нарисовал опытный
архитектор). Мы еѐ уточняли и обсуждали по
мере продвижения разработки. Кстати,
обсуждали устно, прямо с архитектором, а
аналитики так и занимались чем-то своим, пока Рис. 8. Центральная роль модели предметной
не пришло время писать пользовательскую области в дизайне системы
документацию…
Проект был успешно сделан. В При создании структуры хранения данных в
промышленную эксплуатацию внедрили на реляционной СУБД учитываются вопросы
месяц раньше срока (хотя и в неполной нормализации и денормализации, создания
функциональности). индексов для эффективного извлечения данных,
наложения нужных ссылочных ограничений (FK)
4. Реализуемость модели и проверок (CHECK). Производится оптимизация
при помощи partitioning-а, специальных
До сих пор ничего особенно нового не индексов, архивирования и т.д. Но категорически
описано. Так причем здесь Agile в целом и DDD в неправильно все эти нюансы тащить изначально
частности? в саму модель предметной области – это всего
Ключевой момент заключается в лишь особенности реализации.
реализуемости модели предметной области:
Таблица 1. Соответствие концепций
в основе дизайна программного кода бизнес-
логики должна лежать именно модель СУБД Модель ОО-язык
предметной области; таблица сущность класс
код и модель должны соответствовать друг поле атрибут свойство
другу, причем по коду модель должна FK Связь ссылка
восстанавливаться без особых затруднений хр. процедура действие метод
(reverse engineering), пускай и вручную;
в создании модели должны принимать Что касается разработки бизнес-логики, то
участие разработчики (иначе они еѐ не здесь приходит на помощь весь стандартный
примут и не будут ей следовать в полной инструментарий из XP: unit-тестирование, TDD,
мере); рефакторинг. Единственно, и по сей день нет
лучшие проектные силы нужно направлять достойной технологической платформы (каждый
именно на создание core-части бизнес- из ORM-ов обладает своими недостатками и
логики, так как ошибки в ней обходятся зачастую принуждает к «кривым» решениям и
особенно дорого (зачастую приводит к плохой инкапсуляции). Достойные идеи и
необратимой порче ценных данных и/или шаблонные решения (хотя, лично я, не все их
финансовым потерям). разделяю) можно найти в [21], [22], [16]. Есть так
же хороший обзор и подборка литературы в [17].

7. Удивительно, но и в GUI модель предметной эксперты/гуру ограничатся советами и
области играет немаловажную роль. Как рекомендациями, а уже следовать им или нет
минимум, это готовая терминология (чтобы не – это дело команды, так как ей с этим жить.
было такого, что одна и та же вещь в разных И самое главное: разделите крупную модель
частях интерфейса называется по-разному). на части (блоки). По функциональности.
Кроме того, это хорошее приближение для Чтобы каждая часть внутри была сильно
создания форм ввода и общих табличных форм связанной, а между собой как можно меньше.
просмотра. Единственно, не надо сильно Реализуйте бизнес-логику такими частями.
увлекаться такой «генерацией» интерфейсов по Каждую из частей детализируйте и
модели – тяжело будет обеспечить достойный уточняйте непосредственно перед началом еѐ
уровень удобства (usability). реализации. В итоге у вас получится
несколько связанных моделей: одна общая
5. Как организовать процесс без каких-либо специальных подробностей, а
дальше на каждую из частей по детальной
Процесс проектирования – штука тонкая и во проработанной «подмодели». Это отлично
многом индивидуальная, хотя несколько общих работает и очень похоже на то, как
рекомендаций дать можно: развивают и уточняют модель в FDD.
Выделите вначале проекта несколько дней на
создание чернового варианта модели 6. Типичные ошибки
предметной области. Нарисуйте еѐ просто на
доске без лишних подробностей и без Как известно, лучше всего учиться на чужих
оглядки на каллиграфию, затем ошибках. Следующие анти-паттерны часто
сфотографируйте. Пускай это будет одним из встречаются в процессе создания моделей
первых действительно полезных артефактов предметной области:
по проекту. Не переживайте, что итоговая 1. Попытки создания общей модели бизнеса в
модель будет иметь не так много общего с отрыве от контекста конкретной ИС и без
этим черновиком – главное, чтобы была оглядки на реализуемость («астронавтика
хорошая отправная точка. моделирования»).
Избегайте создания длинных «пищевых 2. Модель нарисована одной группой людей,
цепочек» в стиле Бизнес анализ разработкой занимается другая группа, в
Системный анализ Архитектура Дизайн результате при разработке модель не
Код. Вместо этого, привлекайте используется (либо используется не
разработчиков (пускай не всех, но хотя бы полностью).
ключевую часть) к прямому общению с 3. Модель предметной области создается
экспертами в предметной области, исключительно архитектором и/или
моделируйте обязательно при их участии аналитиками, а разработчикам она
(помните, что модель должна быть преподносится как незыблемая данность
реализуемой, а это по-настоящему чуют сверху.
только сами разработчики). 4. Модель не верифицируется у экспертов в
Остерегайтесь архитекторов-астронавтов предметной области.
[20], которые давно не ходили по земле, т.е. 5. Общая модель перегружена излишними
не писали production-код. Почти наверняка подробностями и деталями.
они будут навязывать ошибочные и/или 6. Графическая нотация не сопровождается
труднореализуемые решения. В итоге между текстовыми пояснениями. И наоборот: объем
командой разработчиков и архитектором текстовых описаний чудовищен.
будет стена недоверия. Если еще и модель 7. Вместо объектно-ориентированной модели
предметной области будет создавать такой сразу рисуется структура реляционного
архитектор и навязывать еѐ команде, то всѐ – хранения с присущими ему особенностями
амба. (синтетические первичные ключи,
Лучше привлекайте к проекту (в особенности нормализация, индексы и ссылочная
на начальных этапах или в сложные целостность). Как правило, эта проблема
моменты) экспертов/гуру моделирования из характерна для новичков в ОО-
соседних команд или даже подразделений. моделировании.
Например, в нашей компании есть 2-3 таких
незаменимых. Они помогут в моделировании Что же касается воплощения модели в
или хотя бы быстро верифицируют программном коде, то здесь свои «тараканы»:
предлагаемые командой решения, исходя из 1. Бизнес-логику не отделяют от кода,
своего опыта. Только пускай эти реализующего пользовательский интерфейс
(толстые клиенты).

8. 2. Бизнес-логика отделена от интерфейса, но – Не-е-ет!
есть дублирование (часть проверок, которые – Так чего же ты, кума, тогда выделывалась?!
выполняет бизнес-логика, явным образом
повторена в программном коде Мораль. Если не умеете летать, т.е. не
пользовательского интерфейса). владеете такими важными практиками как ОО-
3. В бизнес-логике не используется (или моделирование, DDD и элементы UP, то и нечего
используется не в полной мере) модель «выделываться», т.е. пытаться применить
предметной области, т.е. модель сама по Agile в проектах по созданию больших
себе, а программный код – сам по себе. информационных систем (разобьетесь, да и
4. Через публичное API бизнес-логики можно только).
нарушить высокоуровневую консистентность
данных (например, разрушить инварианты) 8. P.S.
или выполнить запрещенные моделью
действия (например, удалить документ, Еще хотелось бы рассказать о технических
отраженный в учете). Это явные признаки особенностях реализации бизнес-логики:
нарушения инкапсуляции. использовании ORM-фреймворков и их слабых
5. Объектная модель в бизнес-логике местах, метаданных и DSL, вопросах написания
используется исключительно для нужд unit-тестов на бизнес-логику, разделении бизнес-
чтения/записи данных из/в БД и не содержит логики на отдельные пакеты/сборки и т.п. Но
непосредственно бизнес-правил и методов. придется это отложить до следующего раза.
Это, так называемая, анемичная (бескровная) Так что, как говорится, to be continued…
доменная модель [19]. Очень типично для
случаев примитивного использования ORM-
ов (Hibernate, Entity Framework).
Список литературы 3
6. В бизнес-логике используется большое
[1] K. Beck, A. Cockburn, R. Jeffries and J. Highsmith,
количество вспомогательных мелких Manifesto for Agile Software Development,
классов, не отраженных в модели http://agilemanifesto.org, 2001.
предметной области.
7. По ходу разработки модель не уточняется, [2] K. Beck, Test-Driven Development by Example,
т.е. принятые в ходе реализации решения и Addison Wesley, 2002.
изменения не проносятся обратно в модель.
8. Бизнес-логика не рассчитана на [3] P. Coad, E. Lefebvre & J. De Luca, Java Modeling in
конкурентную работу (не выставляются Color With UML: Enterprise Components and Process,
правильные блокировки). Prentice Hall International, 1999.
9. Не используются механизмы, заложенные и
[4] Eric Evans, Domain-Driven Design: Tackling
хорошо реализованные на уровне Complexity in the Heart of Software (Hardcover),
современных СУБД: ссылочная целостность Addison-Wesley, 2004.
(FK), уникальные наборы значений (AK),
обязательность данных (NOT NULL), [5] John Wiley & Sons, Agile Modeling: Effective
ограничения на наборы значений (CHECK), Practices for Extreme Programming and the Unified
транзакционность, построчные блокировки. Process.
[6] Hruby Pavel, Model-Driven Design Using Business
7. Заключение2 Patterns, 2006.
Анекдот-притча. Летят в самолете ворона и
лисица. Ворона ведет себя нагло, постоянно что- 3
Список рекомендуемой литературы получился
то требует у стюардессы: «Подайте мне то,
достаточно большой (хотя в нѐм изрядное количество ссылок
подайте мне сѐ, а это у вас не так, да то не на небольшие статьи и презентации). Дабы
сяк…». Лисица на это смотрела-смотрела и со заинтересовавшемуся читателю было проще освоить азы
словами: «Почему черным все можно, а рыжим DDD, ниже приведена карта памяти «must read», т.е. «читать
обязательно» (числами в кружочках отмечен предполагаемый
нет?!» – тоже стала вести себя нагло и погонять порядок чтения, в квадратных скобках – номера из списка):
стюардесс. В результате экипаж не выдержал и
вышвырнул обеих нахалок из самолета. Падают
они, тут ворона и спрашивает лисицу:
– Ты летать-то хоть умеешь?
2
Идея такого пассажа с использованием известного анекдота
принадлежит моему лучшему другу и коллеге – Стасу
Фомину.

9. [7] Jonathan S. Ostroff1, David Makalsky1, and Richard F.
Paige, Agile Specification-Driven Development, [15] Мартин Фаулер, UML: Основы, 3-е издание,
http://www.cse.yorku.ca/~jonathan/publications/2004/xp20 Символ-плюс, 2005.
04.pdf, 2005.
[16] Tim McCarthy, .NET Domain-Driven Design with
[8] 3rd Annual “State of Agile Development” Survey June- C#: Problem - Design - Solution, Wrox, 2008.
July 2008 (3061 respondents, 80 countries)
[17] Учимся проектировать на основе предметной
[9] Henrik Kniberg, Scrum and XP from the Trenches, области (DDD: Domain Driven Design),
InfoQ, http://www.infoq.com/minibooks/scrum-xp-from- http://habrahabr.ru/blogs/net/61524, HabraHabr, 2009.
the-trenches, 2007 (есть перевод на русский:
http://scrum.org.ua/wp- [18] Гради Буч, Объектно-ориентированный анализ и
content/uploads/2008/12/scrum_xp-from-the-trenches-rus- проектирование с примерами приложений, 3-е
final.pdf) издание, Вильямс, 2008.
[10] Кент Бек, Экстремальное программирование, [19] Martin Fowler, Anemic Domain Model,
Питер, 2002. http://www.martinfowler.com/bliki/AnemicDomainModel.
html, 2003.
[11] Бибичев Андрей, Безудержный рефакторинг или
как не убиться об стену, [20] Джоел Спольски, Не дайте Астронавтам
http://video.yandex.ru/users/stas-fomin/view/1, 2008. Архитектуры вас запугать,
http://local.joelonsoftware.com/wiki/Не_дайте_Астронав
[12] Крэг Ларман, Применение UML 2.0 и шаблонов там_Архитектуры_вас_запугать, 2001.
проектирования, Вильямс, 2008.
[21] Мартин Фаулер, Архитектура корпоративных
[13] Eric Evans on why DDD Matters Today, программных приложений, Вильямс, 2008.
http://www.infoq.com/articles/eric-evans-ddd-matters-
today, InfoQ, 2006 [22] Д. Нильсон, Применение DDD и шаблонов
проектирования: проблемно-ориентированное
[14] Abel Avram & Floyd Marinescu, Domain-Driven проектирование приложений с примерами на C# и
Design Quickly, http://www.infoq.com/minibooks/domain- .NET, Вильямс, 2007.
driven-design-quickly, InfoQ, 2006.