Обзор Feature-Driven Development и Domain-Driven Design
-
Upload
andrey-bibichev -
Category
Technology
-
view
3.855 -
download
3
description
Transcript of Обзор Feature-Driven Development и Domain-Driven Design
FDD & DDD
Бибичев Андрейдекабрь 2009 г.
I. ПреамбулаСамая ценная часть доклада :)
ДЮДЮКИ:
TDD
DDDBDD
FDDVDD
Test-Driven Development
Test-Driven Design
Behaviour-Driven Development
Feature-Driven Development
Value-Driven Development
Самая известнаяпрактика
Нынче очень модное направление проектирования
Сменщик TDD
Одна из самых навороченных
Agile-методологий Как затуманить заказчику мозги
Зачем?
Scrum – это
Всё дело в том, что
дерьмоудобрение
а
Scrum-команда – это чернозем
плодороднаяпочва
Scrum-команда
Поэтому:
внедрив Scrum,мы обычно думаем,что теперь всё будет
цвести и пахнутьхорошо само собой
Product Owner
Но
в действительности
растет бурьянпроблемы только начинаются
Архитекторпотрудился…
И
если ничего не делать, то
почва истощаетсякоманда разваливается
Рука HR-а
Или
всё скатывается к
копанию в земле по локоть
Code-&-Fix
Менеджер
Аналитик
Архитектор
Контроль качества
Итак,
оказывается еще нужны
семяна и техника
идеи и тех. практики и приемы
что выращивать как выращивать
Прибыльный проект
Обратите внимание на слоистую архитектуру
Шо, опять механизация?RUP
DoWhatever(0)
RUP(120+)
Итеративные процессы
Code-&-Fix(1)
XP(13)
Scrum(9)
Agile
Kanban(3)
Lean
Pull-загрузка задачами
(с) «Процессная ось» имени Хенрика Книберга
• Architecture Reviewer / • Business Designer / • Business-Model Reviewer / • Business-Process Analyst / • Capsule Designer / • Change Control Manager / • Code Reviewer / • Configuration Manager / • Course Developer / • Database Designer / • Deployment Manager / • Design Reviewer / • Designer / • Graphic
Artist / • Implementer / • Integrator / • Process Engineer / • Project Manager / • Project Reviewer / • Requirements Reviewer / • Requirements Specifier / • Software Architect / • Stakeholder / • System
Administrator / • System Analyst / • Technical Writer / • Test Analyst / • Test Designer / • Test Manager / • Tester / • Tool Specialist / • User-Interface Designer / • Architectural analysis / • Assess Viability of architectural proof-of-concept / • Capsule design / • Class design / • Construct architectural proof-ofconcept / • Database design / • Describe distribution / • Describe the run-time architecture / •
Design test packages and classes / • Develop design guidelines / • Develop programming guidelines / • Identify design elements / • Identify design mechanisms / • Incorporate design elements / • Prioritize use cases / • Review the architecture / • Review the design / • Structure the implementation model / • Subsystem design / • Use-case analysis / • Use-case design / • Analysis model / • Architectural proof-
of-concept / • Bill of materials / • Business architecture document / • Business case / • Business glossary / • Business modeling guidelines / • Business object model / • Business rules / • Business use
case / • Business use case realization / • Business use-case model / • Business vision / • Change request / • Configuration audit findings / • Configuration management plan / • Data model / • Deployment model / •
Deployment plan / • Design guidelines / • Design model / • Development case / • Development-organization assessment / • End-user support material / • Glossary / • Implementation model / •
Installation artifacts / • Integration build plan / • Issues list / • Iteration assessment / • Iteration plan / • Manual styleguide / • Programming guidelines / • Quality assurance plan / • Reference architecture / • Release notes / • Requirements attributes / • Requirements management plan / • Review record / • Risk
list / • Risk management plan / • Software architecture document / • Software development plan / • Software requirements specification / • Stakeholder requests / • Status assessment / • Supplementary
business specification / • Supplementary specification / • Target organization assessment / • Test automation architecture / • Test cases / • Test environment configuration / • Test evaluation summary / • Test guidelines / • Test ideas list / • Test interface specification / • Test plan / • Test suite / • Tool
guidelines / • Training materials / • Use case model / • Use case package / • Use-case modeling guidelines / • Use-case realization / • Use-case storyboard / • User-interface guidelines / • User-
interface prototype / • Vision / • Work order / • Workload analysis model
Нам бы чего попроще !погибче
II. FDDFeature-Driven Development
История
1997 год: проект для большого сингапурского банка длительность: 15 месяцев
команда: 50 чел
Jeff De Luca
под влиянием подхода Peter Coad-а к моделированию бизнес-процессов
Интересные факты из биографии:• родился в 1964 году• в 1981 году в возрасте 17-ти лет бросил школу и пошел работать в IBM• быстро стал системным инженером, так и не получив высшего образования (самоучка)• в 1993 ушел из IBM (с должности системного стратега) и организовал собственную компанию• в 1995-1999 гг. выполнил полный реинженирингавтоматизации крупного сингапурского банка
А XP родилось на маленьком in-house
проекте, который кончился fail-ом…
Ну и что! Scrum вообщепредлагает
противоестественноемасштабирование при
помощиScrum-of-Scrum
История
1999 год: книга «Java Modeling in Color With UML» один из соавторов книги – Jeff De Luca (вместе с Peter Coad и Eric
Lefebvre)
в 6-ой главе было дано краткое описание FDD
Всего одна глава!Так – между делом…
По Scrum & XP пришлось написать куда больше книг.
История
2002 год: книга «A Practical Guide To Feature-Driven Development» Stephen Palmer, Mac Felsing
Автор продолжил заниматься делом, а
не исключительноличным PR-ом…
Шикарный подкаст на 40 минут
Feature
<действие> <результат> <кем|чем|чего|для|к> <объект>
<action> the <result> <by|for|of|to> a(n) <object>
Примеры:
Вычислить суммарный объем продаж
Calculate the total amount of a Sale
Определить последнее изменение наличных в кассе для кассира
Determine the most recent Cash Register Assignment for a Cashier
Шаблон именования Feature (функции):
Всегда в терминологии предметной области!Должна быть понятна значимость для бизнеса
Очень похоже наUser Story,
но нет необходимости изобретать персонажи…
Конечно! Каждый считает своим долгом предложить
свой формат для требований. Ладно хоть
Scrum от этого удержался...
Группировка
Область (Major Feature Set, Subject Area) АРМ Кассира
Набор (Feature Set, Activity) Оплата товара
Функция (Feature) Снять деньги с карточки
Дык, это же полный аналог Themes и Epics
при работе с User Stories
Требования к Feature List
Каждая feature должна быть простой
Каждая feature должна быть ценна(хотя бы понятна) заказчику
Каждая feature должна быть проверяема
Каждый feature set может быть закреплен за ведущим разработчиком(Chief Developer)
Feature List должен быть коротким(на столько, на сколько возможно)
Да-да, узнаю старый добрый INVEST:
Independent, Negotiable, Valuable, Estimable,
Small, Testable
Схема процесса
Разработка общей модели
Составление списка функций
Планирование
Build by featureDesign by feature
Список функций(Feature list)
План разработки(A development plan)
Диаграмма классовпредметной области
Отгрузка!
1 – 3 недели
Вау! Здесь есть начальная фаза
проекта!!!Чувствуется, что автор из
IBM…
Процесс по шагам 1:
создание общей модели42
Участвуют:
Главный архитектор
Ведущие разработчики (Chief Developers)
Эксперты в предметной области
Подготовка к созданию:
Выслушивают эксперта в предметной области
По необходимости изучают документы
Обсуждения между собой
Наконец-тознакомые роли!
Архитектор, ведущий разработчик – и снова
здравствуйте
Процесс по шагам 1:
создание общей модели44
Создание модели:
Обязательно разбиваются на небольшие группы
Каждая группа создает свою модель (диаграмму классов)
После этого собираются все вместе, обсуждают различия, выбирают/формируют итоговые решения
В результате:
Диаграмма классов (без детализации)
Комментарии почему выбрано такое решение,альтернативные решения
UML и создание «конкурирующих» моделей – мне это
определенно нравится!
Тоже мне, открыли Америку – всё это
известно со времен Model-Driven
Development/Architecture(MDD/MDA)
Процесс по шагам 2:
формирование Feature List47
Участвуют:
Как и при формировании общей модели
В результате:
Feature List,сгруппированный в наборы (Feature Set),разделенные по областям (Subject Area)
Интересно, а как потом учитываются изменения в требованиях и сколько
сил на это уходит?
Процесс по шагам 3:
планирование49
Основания для планирования: Наборы функций – итерации
Последовательность итераций определяется исходя из:
взаимосвязи функций с точки зрения реализации
сложности набора функций
наличия рисков при реализации функций
равномерное распределение загрузки разработчиков
Участвуют: Руководитель проекта
Ведущие разработчики
В результате:
График реализации наборов функций (Набор – дата)
Ведущие программисты, закрепленные за наборами (Набор – ответственный)
Всем классам назначены владельцы (Класс – владелец)
Что-то это уже конкретно попахивает
водопадом…Да еще персональное
владение кодом… Бррр
Скажи спасибо, что хоть диаграммы Гантастроить не надо
Для тех, кто успел забытьсхему процесса:
Разработка общей модели
Составление списка функций
Планирование
Build by featureDesign by feature
Список функций(Feature list)
План разработки(A development plan)
Диаграмма классовпредметной области
Отгрузка!
1 – 3 недели
Процесс по шагам 4:
Design by feature53
Задачи:
Формирование команд на итерацию
ведущие разработчики динамически формируют команды на итерацию
исходя из того, какие классы затрагивает реализация заданного набора функций (берутся их владельцы)
обычно команды не большие (около 5 человек)
(to be continued)
Динамическое формирование команд на
итерацию – класс!А то:
«слаженная команда –это очень ценно»…
Так их!
Процесс по шагам 4:
Design by feature55
Задачи:(продолжение)
Обзор затрагиваемой предметной области
Изучение необходимых документов
Составление диаграмм взаимодействия
Уточнение и детализация соответствующейчасти диаграммы классов
Написание заголовков методов
В результате:
Краткое описание набора функций, дополнительные комментарии
Диаграммы взаимодействия
Объектная модель (уточнения, исправления), заголовки классов
Задания (To Do) в системе ведения дел для каждого участника команды
Вот! Спецификация API и персональное назначение задач – сразу чувствуется старая школа! И никаких, понимаешь, соплей про
самоорганизацию и кросс-функциональность…
Процесс по шагам 5:
Build by feature57
Задачи: Реализация классов и методов
Code Inspection (Code Review)
до unit-тестирования!
самой командой или даже другой (по решению ведущего программиста)
Unit-тестирование
тесты на класс пишет сам владелец класса
Интеграция (Promote to Build)
Уточнение и детализация соответствующей части диаграммы классов
В результате: Проинспектированные классы и методы
Классы, допущенные в основной ствол проекта
Реализованная функциональность, понятная заказчику (client-valued features)
Супер: вместо парного программирования – Code Inspection/Review; а вместо
мантры «Red-Green-Refactor»– просто написание Unit-
тестов (причем после реализации).
Ну и правильно! Всё равно опросы общественного
мнения показывают, что в парах мало кто кодит, да и
тесты до реализации писать дико – некомпилится ведь!
Важный нюанс
• в FDD нет жесткого time-boxing-а итерации:
– итерация не заканчивается, пока все взятые в неё feature-и не доделают
– т.е. недоделанные feature-и не перетекают в следующую итерацию – их дожимают в текущей, растягивая оную
Разумно, но что они при этом делают со своим
план-графиком?...
Отслеживание хода процесса
62 Стандартная пропорция:
За счет этого ведется графическое отображение хода выполнения:
Обзор
модели
Детализация
модели
(дизайн)
Инспекция
дизайна
Кодирование Инспекция
кода
Интеграция
1% 40% 3% 45% 10% 1%
Отслеживание хода процесса:
для всего проекта63
Области
Наборы функций
Эта штука посильнее будет всяких
Burn-down-ов и –up-ов:и бизнесам показать не
стыдно, и на конфекозырнуть.
--------- Как некий итог ---------
XP
SCRUM
FDD
Уровень процессов
Жесткостьпроцессов
Управлениепроектом
Кодирование
Анархия Водопад
Управлениепроектами
Переченьтребований,Итерации
Unit-тесты,Стандарткодирования,Cont. Integration
Самоорг. команда,Daily Meetings
Индикацияпрогресса
III. DDDDomain-Driven Design
История
2004 годEric Evans
«Domain-Driven Design - Tackling Complexity in the Heart of Software»
Domain (словарь)
• наследственная собственность; имение, поместье; земли; владение
• территория, зона, область, район (отмеченные некоторыми физическими особенностями)
• сфера (интересов), поле (деятельности), область (знаний)
• область определения (мат.)
e.g. DNS
Домен поля таблицы в БД
В данном случае этот смысл
Business Domain
Т.е. это о
и
Business Logic
Предметной области
Бизнес-логики
«Attention was diverted away from rich logic and deep solutions, because there was so much value in just getting data onto the web, along with very simple behavior.
But now that basic level of web usage has largely beenassimilated, and projects are starting to get more ambitious again about business logic.»
Еще раз вспомним про FDD:
Разработка общей модели
Составление списка функций
Планирование
Build by featureDesign by feature
Список функций(Feature list)
План разработки(A development plan)
Диаграмма классовпредметной области
Отгрузка!
1 – 3 недели
DDD
Центральная роль в мышлении,
проектировании, реализации
Пример: есть сайт конференции, надо сделать голосование за доклад
О чем вы прежде всегоначнете думать?
О чем вы прежде всегоначнете думать?
votes
О чем вы прежде всегоначнете думать?
О чем вы прежде всегоначнете думать?
/
Три аспекта DDD
Внимание! Очень важно!
Компоненты нижележащего слояне должны зависеть от
компонентов вышележащегони при каких обстоятельствах
!!!
Постоянно себя спрашивайте:можно ли, используя public API доменной
модели, нарушить целостность, согласованность и консистентность данных?
Хоцца «аналогов» SQL и xxxMyAdminно для компонентов DomainModel, а не СУБД
Этому посвящен значительный объем
всех книг, поэтому здесь мы пропустим
Используете ORM => У вас DDD
!!!
Hibernate Ruby on Rails
http://www.martinfowler.com/bliki/AnemicDomainModel.html
По идее, всё нацелено на достаточно сложные модели:
Но на практике эффективно используетсяи для несложных предметных областей
http://www.infoq.com/presentations/rebuild-guardian-ddd-wills
http://www.infoq.com/presentations/rebuild-guardian-ddd-wills
http://www.infoq.com/presentations/rebuild-guardian-ddd-wills
IV. ЗаключениеВ стиле «Демотиваторы»
«На кой мне это всё?»
Есть Vision
и feedback
и в проектеориентируюсь
яки рыба в воде
артефакты
На одном Scrum-е далеко не уедешь
ВнедрениеScrum
Не подумав вовремя об этом, вы
действуете как кальсонные гномы
Спасибо за внимание!
[email protected]://www.google.com/profiles/biBIGone