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.

1. Введение

Agile популярен, Agile повсеместно

внедряется, все переходят на Agile. Но как только

команда осваивает базовые вещи – итерации,

жесткие временные рамки (time-boxing),

эффективные коммуникации, командную работу

и совместные обязательства (commitment), –

возникает острое ощущение, что чего-то всѐ же

не хватает. И если проект небольшой (два-три

месяца работы команды из 4-7 человек), то, скорее всего, особых проблем не возникнет – вы

успеете сделать проект до того, как остро

осознаете, в чем же загвоздка. На проекте

средних размеров (около полугода или даже года

работы типичной Agile-команды) уже можно

успеть испугаться, но за счет трудовых подвигов

и неординарных личностей такие проекты тоже

чаще всего успешно выполняются.

А что делать с большими проектами (скажем,

от 10-15 чел.лет)? Здесь без какого-то общего

проектирования и дизайна уже почти невозможно

– простой инкрементальный подход приводит к

экспоненциальному росту сложности внесения

изменений, возникают ситуации из серии «в

одном месте прилепили – в другом отвалилось».

Более того, разработка успешных систем не

заканчивается в момент ввода в боевую эксплуатацию – такие системы развиваются

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

команд. В таких условиях экстремально важно с

одной стороны сохранить качество и надежность

решения, а с другой – не потерять темпы

развития, т.е. наращивания/модификации

функциональности под растущие/меняющиеся

потребности бизнеса.

В практике компании «Заказные

ИнформСистемы» большинство проектов

именно такие: самые долгожители уже

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

развития. Ниже на графике приведена динамика

роста функциональности одной из таких систем

(за начало отсчета взят момент ввода в боевую

эксплуатацию, а объем функциональности в этот

момент – за 100%):

Рис. 1. Темпы развития функциональности ИС

Так как же быть в подобных ситуациях? Как преодолеть эскалацию сложности? В чем «секрет

молодости» больших проектов?

Многие вспоминают об Унифицированном

Процессе (Unified Process, UP). Но он такой

большой и такой унифицированный, что в нем

легко заблудиться и не найти того инструмента,

который вам поможет. Кроме того, хотелось бы

остаться в рамках Agile-идеалов [1]:

невысокая цена поздних внесений изменений

в начальные требования;

максимальная вовлеченность самих

разработчиков в процесс проектирования и

дизайна;

минималистичная документация (Agile-

спецификации и т.п.);

программный код, из которого легко понять

основные проектные решения.

Данный материал посвящен именно этому

вопросу. Причем речь будет идти не о

произвольных компьютерных системах, а об их

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-сегмент .

Дабы разобраться в этом нагромождении

аббревиатур, подойдем с другой стороны – от

конкретных Agile-методологий.

2.1. Scrum

Что предлагает наиболее популярная Agile-методология [8] для решения задач

проектирования и дизайна ПО? Ответ простой:

ничего.

Scrum вообще не касается каких-либо

технических моментов. В связи с этим, данную

методологию очень часто дополняют

отдельными практиками из eXtreme Programming

(XP) – получается «XP driven by Scrum» [9].

2.2. XP

Экстремальное программирование

пропагандирует инкрементальный дизайн, а

спасаться предлагает при помощи таких практик,

как разработка на основе тестов (TDD) и

рефакторинга (Refactoring – продвинутое

«причесывание» кода) [10]. Unit-тесты писать – это точно полезно (хотя до

сих пор далеко не все проектные команды

находят в себе силы обеспечивать приемлемое

покрытие кода автоматическими тестами, в

основном ссылаясь на нехватку времени). Писать

тесты до реализации (как того требуют буквы

TDD) может быть тоже оправданно с точки

зрения конструирования API, которым удобно

пользоваться (хотя, в этой роли такая вещь как

«мысленный эксперимент» тоже весьма не

дурна). Но можно ли спроектировать большую

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

да ещѐ, чтобы дизайн системы был из них

понятен и легко извлекаем? Лично я таких

примеров не встречал. Кроме того, не понятно,

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

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

Кстати, Agile-specification-Driven Development

есть не что иное, как помесь TDD и Design-By-

Contract. Т.е., опять же, ничего принципиально

нового (по сравнению с TDD) не предлагает.

Рефакторинг (Refactoring) – широко

распространенная и популярная практика. Правда

и здесь могут быть свои подводные камни и

поведенческие анти-паттерны [11]. Как бы то ни

было, рефакторинг нацелен в первую очередь на

относительно локальные улучшения, а чтобы

исправить серьезные ошибки или недостатки

общего проектирования, придется прибегать к

реинжинирингу, что уже и тяжело, и рискованно,

и долго.

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

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

неясным.

2.3. FDD

К сожалению, Feature-Driven Development

(FDD) не так подробно описана в литературе.

Этой методологии посвящена всего одна глава в

[3]. Что из нее можно почерпнуть:

FDD нацелена на большие проекты

(изначально применена при создании серьезной банковской системы);

в процессе выделяется начальный этап

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

предметной области при помощи UML;

причем создается несколько

«конкурирующих» моделей (независимыми

командами), а затем совместными усилиями

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

решения из каждой;

в рамках итераций разрабатывается

отдельный кусочек модели, для чего он

вначале уточняется и детализируется.

Рис. 2. Схема процесса в FDD

Т.е. что мы видим: серьезный упор сделан на

центральную роль модели предметной области,

широко используется UML, а в процесс

разработки плотно встроены дизайн-сессии. Всѐ

очень похоже на Unified Process, только проще и

конкретнее.

2.4. OpenUP и AgileUP

Прямые «наследники» Unified Process (UP). В

рамках этих методологий подразумевается

широкое использование как моделирования в

целом, так и UML в частности. В рамках UP

наибольшую популярность получили два

подхода:

1. Model-Driven Design/Development

(разработка на основе модели);

2. Model-Driven Architecture (архитектура на

основе модели).

По большому счету, одно от другого

отличается только акцентами – и там, и там ключевую роль играет модель [12]. Просто в

случае Model-Driven Architecture

программированию отводится второстепенная

роль – в идеале автоматическая кодогенерация по

подробным и точным UML-диаграммам

(использование UML, как языка

программирования). Надо отметить, что такой

подход (автоматическая кодогенерация на основе

диаграмм) показал свою серьезную

ограниченность на практике: сил на создание и

поддержание столь подробных моделей уходит

больше, чем на написание кода, а сами модели

становятся сильно утяжеленными,

перегруженными и малопонятными.

2.5. The last but not the least

Итак, из упомянутого семейства xDD, остался

только Domain-Driven Design (DDD), т.е. дизайн

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

Этот подход не связан напрямую ни с одним

из процессов, хотя возник именно в Agile-

сообществе. Грубо говоря, это Agile-наследник

MDD с уклоном в вопросы реализуемости

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

Сейчас тема DDD очень популярна и по-

прежнему остается проблемной. Эрик Ивенс (Eric

Evans – автор DDD) в одном из интервью сетует

на широкое распространение неверных трактовок и заблуждений [13]: «One thing that excites me is

when people take the principles I talked about in my

book and use them in ways I never expected».

Так что обязательно прочтите книгу Эрика [4],

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

Кроме того, на InfoQ есть краткое введение в

DDD [14], которое можно скачать бесплатно.

Изложенный ниже материал опирается на

сочетание FDD, MDD и DDD, причем по духу и

смыслу ближе всего именно к DDD.

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

Итак, и в FDD, и в MDD, и в DDD

центральную роль играет модель предметной

области (domain model). Что это и как это?

Модель предметной области, как и любая

другая модель, является упрощенным

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

достаточной степени близка к действительности.

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

информационной системы. Если модель будет

слишком простой, система будет почти

бесполезна (не будет удовлетворять и малой

толики реальных бизнес-потребностей). И не

следует путать простоту и примитивность!

3.1. ООП

Физики в своих моделях используют

математический аппарат плюс графические

схемы (будь то изображение механической

системы или диаграммы Фейнмана). В IT-же для

моделирования уже последние лет 20 принято

придерживаться объектно-ориентированного

подхода (ООП) [18].

Соответственно, и при моделировании

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

терминах объектов, их связей, свойств и методов.

Это дважды выгодно: во-первых, накоплен

большой опыт объектно-ориентированного

проектирования и мышления; а во-вторых,

современные языки являются объектно-

ориентированными, так что будет проще в

реализации построенной модели (а это крайне

важно – см. ниже).

Единственно, когда речь идет о предметной

области и бизнес-логике, принято использовать

несколько уточненную терминологию:

сущность (entity) – объект предметной

области, обладающий уникальной

идентификацией (identity);

атрибут (attribute) сущности – свойство

объекта предметной области, выраженное в

виде значения простого типа (число/дата/т.д.) или связи с другой сущностью;

действие (action) над сущностью – в

программном коде выражается методом

класса сущности.

3.2. Использование UML

В качестве графической нотации традиционно

используют UML в режиме эскизного

моделирования [15]. Он не самым лучшим

образом подходит для этих целей, но ничего лучше до сих пор не придумали. Если вам

кажется, что какой-то нестандартный

рисунок/чертежик ярче и четче отражает тот или

иной аспект модели – не смущайтесь и

используйте его (здесь нет догмата).

UML предлагает целый набор различных

видов диаграмм. При моделировании предметной

области чаще всего прибегают к помощи

диаграмм классов. Кроме того, мы (и не только

мы) активно используем диаграммы состояний (в

особенности там, где есть документооборот).

Диаграммы деятельности и диаграммы

последовательности тоже применяются, но

весьма умеренно.

Нравится кому-то UML или нет – это не так

важно, так как на данный момент это стандарт

де-факто.

3.3. Пример: система продажи билетов

на самолет

Как происходит моделирование? А очень

просто: вы (как человек, нечуждый разработке)

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

попутно пытаетесь зарисовывать его слова в виде

диаграмм, делая дополнительные заметки.

Кстати, подавляющее большинство людей из

бизнеса быстро «схватывают» азы нотации и

начинают читать и верифицировать

нарисованные модели.

Например, пусть нас попросили сделать систему продажи авиабилетов. Мы

разговариваем с экспертом в предметной

области1.

Эксперт: Есть аэропорты. Для каждого

известны название на местом языке,

1 Диалог сильно упрощен. В жизни рассказывают и о

выполняемых действиях и операциях, а не только структуре

информации. Но на самом деле это не сильно меняет суть

происходящего.

уникальный латинский код и GPS-

координаты.

Мы:

Рис. 3. Сущность «Аэропорт» и её атрибуты

Эксперт: Аэропорты расположены в

городах. Для каждого города известно его

название (на местном и англ. языках).

Причем известно расстояние от аэропорта до

центра города, к которому он «приписан».

Мы:

Рис. 4. Сущность «Город» и её связь с

«Аэропорт»

Эксперт: Для каждого города есть

информация о стране, в которой он

находится.

Мы:

Рис. 5. Добавляется сущность «Страна»

И так далее… В результате (пофантазируйте

на тему рассказа эксперта сами):

Рис. 6. Эскиз модели предметной области

Не стесняйтесь рисунков от руки – это же эскизное моделирование! И не пытайтесь

уместить на диаграмме все детали, атрибуты и

связи – фиксируйте только важное/основное.

3.4. Словарь терминов

Отличное свойство такой модели: это

готовый словарь терминов. Дальше остается

договориться, что везде (и на интерфейсе, и в

программном коде, и в пользовательской

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

в модели.

Отлично работает! Не нужно составлять

отдельный глоссарий (если только от вас этого не

требуют особые обстоятельства или дотошный

заказчик).

На практике не раз видел, как термины,

подобранные во время совместных сессий

моделирования, затем приживались и активно

использовались в бизнес-среде заказчика.

3.5. Несколько моделей

Не надо думать, что есть одна единственная

«правильная» модель. Нет. Моделей множество:

во-первых, многое зависит от вашего опыта и

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

решениям;

во-вторых, обязательно есть некий контекст,

в котором разрабатывается модель (в

приведенном выше примере это был

контекст покупки авиабилетов, а если бы мы

делали систему регистрации пассажиров на

рейс, то модель была бы другой, так как там

важны и переносы рейсов, и объединение, и

расположение мест в самолете и т.д.).

Не стоит переживать по этому поводу. Это

можно использовать даже во благо: например, как в FDD, создайте несколько

«конкурирующих» моделей, а затем «столкните

их лбами» и получите итоговую.

3.6. История из личного опыта

Первый большой проект, который довелось

мне делать сразу в позиции team lead-а (ну или

вроде того), был связан с разработкой расчетно-

платежной системы для сферы коммунальных

услуг. Действовали по «доморощенной»

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

к нему (вместе с группой разработчиков), уже

было написано большое техническое задание.

Так вот, из всего этого огромного документа

единственное, что мы использовали для

разработки, была диаграмма классов (опять же, в

«доморощенной» нотации), на которой была

изображена предлагаемая модель предметной

области.

Вот небольшой кусочек из этой модели (без

искажений, в оригинальной нотации:

означает связь «*-к- – связь «*-к-

0..1»):

Рис. 7. Фрагмент модели для расчета услуг ЖКХ

Модель была хорошей (еѐ нарисовал опытный

архитектор). Мы еѐ уточняли и обсуждали по

мере продвижения разработки. Кстати,

обсуждали устно, прямо с архитектором, а

аналитики так и занимались чем-то своим, пока

не пришло время писать пользовательскую

документацию…

Проект был успешно сделан. В

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

месяц раньше срока (хотя и в неполной

функциональности).

4. Реализуемость модели

До сих пор ничего особенно нового не

описано. Так причем здесь Agile в целом и DDD в

частности?

Ключевой момент заключается в

реализуемости модели предметной области:

в основе дизайна программного кода бизнес-

логики должна лежать именно модель

предметной области;

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

другу, причем по коду модель должна

восстанавливаться без особых затруднений

(reverse engineering), пускай и вручную;

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

участие разработчики (иначе они еѐ не

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

мере);

лучшие проектные силы нужно направлять

именно на создание core-части бизнес-

логики, так как ошибки в ней обходятся

особенно дорого (зачастую приводит к

необратимой порче ценных данных и/или

финансовым потерям).

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

должна быть центральным элементом в вашем

процессе разработки. Именно на еѐ основании

должны создаваться и структуры хранения

данных, и программный код бизнес-логики, и

даже дизайн GUI.

Рис. 8. Центральная роль модели предметной области в дизайне системы

При создании структуры хранения данных в

реляционной СУБД учитываются вопросы

нормализации и денормализации, создания индексов для эффективного извлечения данных,

наложения нужных ссылочных ограничений (FK)

и проверок (CHECK). Производится оптимизация

при помощи partitioning-а, специальных

индексов, архивирования и т.д. Но категорически

неправильно все эти нюансы тащить изначально

в саму модель предметной области – это всего

лишь особенности реализации.

Таблица 1. Соответствие концепций

СУБД Модель ОО-язык

таблица сущность класс

поле атрибут свойство

FK Связь ссылка

хр. процедура действие метод

Что касается разработки бизнес-логики, то

здесь приходит на помощь весь стандартный

инструментарий из XP: unit-тестирование, TDD,

рефакторинг. Единственно, и по сей день нет

достойной технологической платформы (каждый

из ORM-ов обладает своими недостатками и

зачастую принуждает к «кривым» решениям и

плохой инкапсуляции). Достойные идеи и шаблонные решения (хотя, лично я, не все их

разделяю) можно найти в [21], [22], [16]. Есть так

же хороший обзор и подборка литературы в [17].

Удивительно, но и в GUI модель предметной

области играет немаловажную роль. Как

минимум, это готовая терминология (чтобы не

было такого, что одна и та же вещь в разных

частях интерфейса называется по-разному).

Кроме того, это хорошее приближение для

создания форм ввода и общих табличных форм

просмотра. Единственно, не надо сильно

увлекаться такой «генерацией» интерфейсов по модели – тяжело будет обеспечить достойный

уровень удобства (usability).

5. Как организовать процесс

Процесс проектирования – штука тонкая и во

многом индивидуальная, хотя несколько общих

рекомендаций дать можно:

Выделите вначале проекта несколько дней на

создание чернового варианта модели

предметной области. Нарисуйте еѐ просто на

доске без лишних подробностей и без

оглядки на каллиграфию, затем

сфотографируйте. Пускай это будет одним из

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

по проекту. Не переживайте, что итоговая

модель будет иметь не так много общего с

этим черновиком – главное, чтобы была

хорошая отправная точка.

Избегайте создания длинных «пищевых

цепочек» в стиле Бизнес анализ

Системный анализ Архитектура Дизайн

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

ключевую часть) к прямому общению с экспертами в предметной области,

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

(помните, что модель должна быть

реализуемой, а это по-настоящему чуют

только сами разработчики).

Остерегайтесь архитекторов-астронавтов

[20], которые давно не ходили по земле, т.е.

не писали production-код. Почти наверняка

они будут навязывать ошибочные и/или

труднореализуемые решения. В итоге между

командой разработчиков и архитектором

будет стена недоверия. Если еще и модель

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

архитектор и навязывать еѐ команде, то всѐ –

амба.

Лучше привлекайте к проекту (в особенности на начальных этапах или в сложные

моменты) экспертов/гуру моделирования из

соседних команд или даже подразделений.

Например, в нашей компании есть 2-3 таких

незаменимых. Они помогут в моделировании

или хотя бы быстро верифицируют

предлагаемые командой решения, исходя из

своего опыта. Только пускай эти

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

рекомендациями, а уже следовать им или нет

– это дело команды, так как ей с этим жить.

И самое главное: разделите крупную модель

на части (блоки). По функциональности.

Чтобы каждая часть внутри была сильно

связанной, а между собой как можно меньше.

Реализуйте бизнес-логику такими частями.

Каждую из частей детализируйте и уточняйте непосредственно перед началом еѐ

реализации. В итоге у вас получится

несколько связанных моделей: одна общая

без каких-либо специальных подробностей, а

дальше на каждую из частей по детальной

проработанной «подмодели». Это отлично

работает и очень похоже на то, как

развивают и уточняют модель в FDD.

6. Типичные ошибки

Как известно, лучше всего учиться на чужих

ошибках. Следующие анти-паттерны часто

встречаются в процессе создания моделей

предметной области:

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

отрыве от контекста конкретной ИС и без

оглядки на реализуемость («астронавтика

моделирования»).

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

результате при разработке модель не

используется (либо используется не

полностью).

3. Модель предметной области создается

исключительно архитектором и/или

аналитиками, а разработчикам она

преподносится как незыблемая данность

сверху.

4. Модель не верифицируется у экспертов в

предметной области.

5. Общая модель перегружена излишними

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

6. Графическая нотация не сопровождается

текстовыми пояснениями. И наоборот: объем

текстовых описаний чудовищен.

7. Вместо объектно-ориентированной модели сразу рисуется структура реляционного

хранения с присущими ему особенностями

(синтетические первичные ключи,

нормализация, индексы и ссылочная

целостность). Как правило, эта проблема

характерна для новичков в ОО-

моделировании.

Что же касается воплощения модели в

программном коде, то здесь свои «тараканы»:

1. Бизнес-логику не отделяют от кода,

реализующего пользовательский интерфейс

(толстые клиенты).

2. Бизнес-логика отделена от интерфейса, но

есть дублирование (часть проверок, которые

выполняет бизнес-логика, явным образом

повторена в программном коде

пользовательского интерфейса).

3. В бизнес-логике не используется (или

используется не в полной мере) модель

предметной области, т.е. модель сама по

себе, а программный код – сам по себе. 4. Через публичное API бизнес-логики можно

нарушить высокоуровневую консистентность

данных (например, разрушить инварианты)

или выполнить запрещенные моделью

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

отраженный в учете). Это явные признаки

нарушения инкапсуляции.

5. Объектная модель в бизнес-логике

используется исключительно для нужд

чтения/записи данных из/в БД и не содержит

непосредственно бизнес-правил и методов.

Это, так называемая, анемичная (бескровная)

доменная модель [19]. Очень типично для

случаев примитивного использования ORM-

ов (Hibernate, Entity Framework).

6. В бизнес-логике используется большое

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

предметной области.

7. По ходу разработки модель не уточняется,

т.е. принятые в ходе реализации решения и

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

8. Бизнес-логика не рассчитана на

конкурентную работу (не выставляются

правильные блокировки).

9. Не используются механизмы, заложенные и

хорошо реализованные на уровне

современных СУБД: ссылочная целостность

(FK), уникальные наборы значений (AK),

обязательность данных (NOT NULL),

ограничения на наборы значений (CHECK),

транзакционность, построчные блокировки.

7. Заключение2

Анекдот-притча. Летят в самолете ворона и

лисица. Ворона ведет себя нагло, постоянно что-то требует у стюардессы: «Подайте мне то,

подайте мне сѐ, а это у вас не так, да то не

сяк…». Лисица на это смотрела-смотрела и со

словами: «Почему черным все можно, а рыжим

нет?!» – тоже стала вести себя нагло и погонять

стюардесс. В результате экипаж не выдержал и

вышвырнул обеих нахалок из самолета. Падают

они, тут ворона и спрашивает лисицу:

– Ты летать-то хоть умеешь?

2 Идея такого пассажа с использованием известного анекдота

принадлежит моему лучшему другу и коллеге – Стасу

Фомину.

– Не-е-ет!

– Так чего же ты, кума, тогда выделывалась?!

Мораль. Если не умеете летать, т.е. не

владеете такими важными практиками как ОО-

моделирование, DDD и элементы UP, то и нечего

«выделываться», т.е. пытаться применить

Agile в проектах по созданию больших

информационных систем (разобьетесь, да и только).

8. P.S.

Еще хотелось бы рассказать о технических

особенностях реализации бизнес-логики:

использовании ORM-фреймворков и их слабых

местах, метаданных и DSL, вопросах написания

unit-тестов на бизнес-логику, разделении бизнес-

логики на отдельные пакеты/сборки и т.п. Но

придется это отложить до следующего раза.

Так что, как говорится, to be continued…

Список литературы3

[1] K. Beck, A. Cockburn, R. Jeffries and J. Highsmith,

Manifesto for Agile Software Development, http://agilemanifesto.org, 2001.

[2] K. Beck, Test-Driven Development by Example,

Addison Wesley, 2002.

[3] P. Coad, E. Lefebvre & J. De Luca, Java Modeling in

Color With UML: Enterprise Components and Process,

Prentice Hall International, 1999.

[4] Eric Evans, Domain-Driven Design: Tackling

Complexity in the Heart of Software (Hardcover),

Addison-Wesley, 2004.

[5] John Wiley & Sons, Agile Modeling: Effective

Practices for Extreme Programming and the Unified

Process.

[6] Hruby Pavel, Model-Driven Design Using Business Patterns, 2006.

3 Список рекомендуемой литературы получился

достаточно большой (хотя в нѐм изрядное количество ссылок

на небольшие статьи и презентации). Дабы

заинтересовавшемуся читателю было проще освоить азы

DDD, ниже приведена карта памяти «must read», т.е. «читать

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

порядок чтения, в квадратных скобках – номера из списка):

[7] Jonathan S. Ostroff1, David Makalsky1, and Richard F.

Paige, Agile Specification-Driven Development, http://www.cse.yorku.ca/~jonathan/publications/2004/xp20

04.pdf, 2005.

[8] 3rd Annual “State of Agile Development” Survey June-July 2008 (3061 respondents, 80 countries)

[9] Henrik Kniberg, Scrum and XP from the Trenches,

InfoQ, http://www.infoq.com/minibooks/scrum-xp-from-the-trenches, 2007 (есть перевод на русский:

http://scrum.org.ua/wp-

content/uploads/2008/12/scrum_xp-from-the-trenches-rus-

final.pdf)

[10] Кент Бек, Экстремальное программирование,

Питер, 2002.

[11] Бибичев Андрей, Безудержный рефакторинг или

как не убиться об стену,

http://video.yandex.ru/users/stas-fomin/view/1, 2008.

[12] Крэг Ларман, Применение UML 2.0 и шаблонов проектирования, Вильямс, 2008.

[13] Eric Evans on why DDD Matters Today,

http://www.infoq.com/articles/eric-evans-ddd-matters-today, InfoQ, 2006

[14] Abel Avram & Floyd Marinescu, Domain-Driven

Design Quickly, http://www.infoq.com/minibooks/domain-

driven-design-quickly, InfoQ, 2006.

[15] Мартин Фаулер, UML: Основы, 3-е издание,

Символ-плюс, 2005.

[16] Tim McCarthy, .NET Domain-Driven Design with

C#: Problem - Design - Solution, Wrox, 2008. [17] Учимся проектировать на основе предметной

области (DDD: Domain Driven Design), http://habrahabr.ru/blogs/net/61524, HabraHabr, 2009.

[18] Гради Буч, Объектно-ориентированный анализ и

проектирование с примерами приложений, 3-е издание, Вильямс, 2008.

[19] Martin Fowler, Anemic Domain Model,

http://www.martinfowler.com/bliki/AnemicDomainModel.html, 2003.

[20] Джоел Спольски, Не дайте Астронавтам

Архитектуры вас запугать, http://local.joelonsoftware.com/wiki/Не_дайте_Астронав

там_Архитектуры_вас_запугать, 2001.

[21] Мартин Фаулер, Архитектура корпоративных программных приложений, Вильямс, 2008.

[22] Д. Нильсон, Применение DDD и шаблонов

проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и

.NET, Вильямс, 2007.