Обзор Feature-Driven Development и Domain-Driven Design (Андрей Бибичев на AgileDays-2009)

Ссылки сюда (1) →

Обзор Feature-Driven Development и Domain-Driven Design

Докладчик

Андрей Бибичев

• http://agiledays.ru/reports/view/4/

---

Эрик Эванс (Eric Evans) в своей книге о Domain-Driven Design (DDD) пишет: «Software development is all design» (Разработка ПО — это всецело дизайн/проектирование). И правда: ведь сборка ПО целиком автоматизируется и не требует ощутимых усилий со стороны проектной команды.

И что же в Agile есть на тему дизайна/проектирования? Scrum об этом молчит. В eXtreme Programming (XP) есть такие практики, как Test-Driven Development (TDD) и Refactoring, но они работают, скорее, на уровне дизайна отдельных классов и их имплементации («микро-дизайн»). А как же быть с архитектурой и «макро-дизайном»?!

«Лучшие собаководы» (гуру архитектуры и проектирования) рекомендуют сочетать проектирование сверху-вниз и реализацию снизу-вверх, то есть макро- и микро- дизайны. Agile-процесс под названием Feature-Driven Development (FDD) как раз базируется на таком подходе. В докладе дается краткое описание как самого процесса, так и его истории. Проводятся параллели с XP и Scrum, дается анализ сильных и слабых сторон, а также области применимости.

Казалось бы, причем здесь Domain-Driven Design (DDD)? В FDD краеугольным камнем является модель предметной области (Domain Model). В DDD — тоже. Но если FDD — это прежде всего процесс, то DDD является подходом к проектированию и реализации, причем этот подход замечательно сочетается с любым Agile-процессом. Кроме того, в DDD много внимания уделено «сшивке» макро- и микро- дизайнов: описаны общие принципы имплементации модели в программном коде, приводятся готовые образцы (patterns) реализации.

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

---

Андрей убеждал не останавливаться на тупом, «карго-культовом», внедрении SCRUM-практик, уподобляясь кальсонным гномам, а обязательно развивать архитектурные практики, такие как Domain-driven design и Feature Driven Development, настаивая, что для достаточно большого проекта (от 20 человеко-лет) это не «модное дополнение к SCRUM», а именно необходимый ингридиент.

В целом, аудитория была в теме — достаточно заметить, что на конференции был десант из Нижегородского Интела, где ребята выступали с близким по теме докладом #TDD + DDD + MVP + GoF + PoEAA= Love!, так что четверть часа после доклада шла дискуссия (есть на видео), на темы:

• Как избежать анемии доменной модели и бизнес-логики — классически инкапсулировать бизнес-логику в объекты или выносить ее на сервисный слой?
• Как должны соотноситься уровень Infrostructure и Domain? Должен ли Domain классически использовать Infrostructure (возможно разделяемую на несколько проектов с разными предметными областями), или, в соответствии с новыми веяниями использовать паттерны «Inversion of Control/Dependency Injection», и Domain ничего не должен знать о Infrostructure, что несколько необычно, но должно давать большой буст при тестировании (можно разгонять тесты, mockiруя тяжелый инфраструктурный слой).
• Оправдано ли экономически, играть во все игры с модными паттернами и практиками — понятно, что все это ради качества, но какой ценой? Может это могут позволить себе только очень богатые компании, для inhouse-разработки, или крупные компании для продуктов с огромными тиражами, но ведь в обычной заказной разработке дилемму «скорость-качество», невыгодно радикально решать в пользу последней.

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

---

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».