В проектах по разработке программного обеспечения участвуют множество различных специалистов, у которых разные роли, разные специализации, своя терминология, свой жаргон. И часто в проекте люди не понимают друг друга. Заказчики не понимают, почему те или иные доработки стоят так дорого. Аналитики вынуждены выступать переводчиками между пользователями и разработчиками. А разработчики работают сразу с двумя моделями системы — с моделью представленной аналитиками и моделью реализованной в коде. Это приводит к тому, что основные усилия расходуются не на разработку полезного функционала, а на попытки удержать обе модели в голове и сопоставить их друг с другом. Методология Domain Driven Design (проектирование на основе предметной области — далее DDD) для решения этой проблемы предлагает в качестве единой опорной точки использовать модель предметной области. Такая модель хорошо понятна заказчикам, служит отличным инструментом для аналитиков. Но важной особенностью такой модели является то, что она может быть напрямую реализована в коде, а значит, пригодна для использования разработчиками. При принятии решения всегда встают вопросы: – Что такое Domain Driven Design? – На каких проектах можно применить DDD? Является ли мой проект таким? – Какова цена и какие риски? – Какие типичные ошибки ждут на пути?

1. Разработчик, аналитик, заказчик —
как найти общий язык?
Николай Гребнев
CUSTIS

2. Ситуация
Организация
Процесс(ы)
ИС

3. Процесс разработки
информационной системы

4. Участники
• Заказчик:
– Методологи
– Пользователи
– Руководство
• Исполнитель:
– Аналитики
– Разработчики
– Тестировщики
– Руководители

5. У каждого участника свое
представление о ИС

6. Каждый говорит на своем языке

7. Заказчик
• SDH
• Оптическая секция
• Сетевой элемент
• СПК (сеть пакетной коммутации)
• Тракт
• …

8. Аналитик
• Документ
• Справочник
• Состояние
• …

9. Разработчик
• Класс
• Метод
• Синглтон
• SOLID
• Датасет
• Биндинг
• …

10. Руководитель
• Сроки
• Бюджет
• …

11. Проблемы
• Непонятно, что делать
• Сделали не то
• Не можем обосновать стоимость работ

12. Непонятно, что делать

13. Сделали не то

14. Стоимость работ

15. Кто виноват?

16. Что делать?

17. Domain Driven Design (DDD)

19. Domain Driven Design
• Единый язык (модель)
• основанный на предметной области
• непосредственно воплощенный в исходном
коде (проектирование по модели, Model
Driven Development)

20. Единый язык
Модель
Переработка Единый
предметной
знаний язык
области

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

22. Все участники проекта
используют единый язык

23. Все требования формулируются
в терминах модели предметной
области

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

25. Основан на предметной области
• Понятия языка имеют смысл в предметной
области
• В основе модели лежит представление всех
участников проекта о предметной области

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

27. Основан на предметной области
Датасет с таблицей
сотрудников
Кадровое
делопроизводство Соединение с БД
Команда на
обновление

28. Основан на предметной области
Личное дело
сотрудника
Кадровое
делопроизводство Сотрудник
Табель УРВ

29. Единый язык непосредственно
воплощен в исходном коде

30. Воплощен в исходном коде
• Требование:
– Зачислить сотрудника в подразделение
начиная с заданной даты

31. Воплощен в исходном коде
DepartmentHistoryRepository.Remove(
from dh in DepartmentHistoryRepository
where dh.EmployeeId = employee.Id &&
dh.DateStart >= date
select dh);
var dhe =
from dh in DepartmentHistoryRepository
where dh.EmployeeId = employee.Id &&
dh.DateStart <= date &&
dh.DateEnd >= date
select dh;
dhe.DateEnd = date.AddDay(-1)
DepartmentHistoryRepository.CreateNew(
employee, date);

32. Воплощен в исходном коде
подразделение.Зачислить(
сотрудник, дата);

33. ЧТО МЫ ПОЛУЧАЕМ?

34. Domain Driven Design
• Средство для формулировки требований и
общения
• Адекватное отражение сложности системы
• Обоснованную стоимость работ

35. Обоснованная стоимость работ
Большая сложность изменений
Масштабные изменения модели
Введение новых понятий
Высокая стоимость

36. СКОЛЬКО ЭТО СТОИТ?

37. Из чего складывается
стоимость?

38. Много общения и согласований
Плотная работа с заказчиком
Высокая прозрачность системы
Меньше гибкости на стороне исполнителя

39. Разработчики должны участвовать в
построении модели предметной области
Общение с заказчиком
Компетенции аналитика у разработчика

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

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

42. А НУЖНО ЛИ ЭТО?

43. На каких проектах применять
DDD?

44. Основная сложность задачи
заключена в предметной
области

45. Очень широкая граница, о
которой необходимо
договариваться с заказчиком

46. ПРИМЕР

47. Распределение товаров по
магазинам
• Сложная предметная область
• Информационные потоки и бизнес-процесс
определяет заказчик
• Технические сложности преодолимы

48. АНТИПРИМЕР

49. Система обмена сообщениями с
высокой пропускной способностью
• Простая постановка задачи
• Информационные потоки и бизнес-процесс
(обмен сообщениями) определяет
исполнитель
• Высокая техническая сложность

50. ТИПИЧНАЯ ОШИБКА

51. Переработка
знаний
Модель
предметной Код
области

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

53. СПАСИБО
Докладчик: Николай Гребнев
e-mail: ngrebnev@gmail.com
slideshare.net: ngrebnev