Domain - Driven Design DDD 1. Введение

1.

Введение

2.

3.

«Большая синяя книга» (BBB)
Domain-Driven Design:
Tackling Complexity in the Heart of Software
Eric Evans
http://bit.ly/evans-ddd-book
http://bit.ly/evans-ddd-since-the-book
сокращенная (и свободная для доступа)
версия этой книги, подготовленная
порталом InfoQ:
Domain Driven Design Quickly

4.

.NET Domain-Driven Design with C#
Problem – Design – Solution
Tim McCarthy
Эта книга – отличный практикум по DDD, содержащий
очень широкий пласт идей
Начинается книга с разработки требований, а
заканчивается реализацией промышленного
приложения

5.

Applying Domain-Driven Design and Patterns
Jimmy Nilsson’s
http://bit.ly/nilsson-ddd-book
«Применение шаблонов проектирования:
проблемно-ориентированное проектирование
приложений с примерами на C# и .NET»
Джимми Нильссона

6.

Patterns, Principles,
and Practices of Domain-Driven Design
Scott Millett, Nick Tune

7.

Implementing Domain-Driven Design
Vaughn Vernon
Реализация методов
предметноориентированного
проектирования
Вон Вернон

8.

Официальный сайт
http://domaindrivendesign.org/
Группа обсуждений
http://tech.groups.yahoo.com/group/domaindrivendesign/
Блог Jimmy Bogard’а
http://www.lostechies.com/blogs/jimmy_bogard/default.aspx
Блог Colin Jack’а
http://colinjack.blogspot.com/
Блог Greg Young’а
http://codebetter.com/blogs/gregyoung/default.aspx
Блог Casey Charlton’а
http://devlicio.us/blogs/casey/
Блог Udi Dahan’а
http://www.udidahan.com/
Введение в Domain-Driven Design
http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

9.

Проблемно-ориентированное
проектирование (DDD) —
это набор принципов и схем, помогающих
разработчикам создавать изящные системы
объектов
При правильном применении оно приводит к
созданию программных абстракций, которые
называются моделями предметных областей
В эти модели входит сложная бизнес-логика,
устраняющая промежуток между реальными
условиями бизнеса и кодом

10.

Проблема
Проблема

11.

Что не так с моделью ?
Разработчик теряет контроль над сложностью продукта

12.

Сложность
предметной
области
Необходимая
составляющая
Сложность
техническог
о решения
Сложность
имеющегося
кода
Общая сложность системы

13.

Одна и та же функциональность реализована
по-разному в разных местах кода
С одним объектом предметной области
связано несколько классов программы
Классы содержат свойства, не являющиеся
атрибутами объектов
Классы не связанны друг с другом, или эта
связь не качественна
Глядя на отдельные классы не понятно о чем
все приложение

14.

THE BIG BALL OF MUD IS NOT ALWAYS AN ANTIPATTERN

15.

Стоимость изменения
25
20
15
10
Долг
5
0
Время

16.

Модель
Код

17.

Код «схватывающий» модель
Создавая программу, которая решает
конкретную текущую проблему и
ограничена этой проблемой, вы в итоге
получаете программу, готовую воспринять
новые идеи и озарения

18.

public boolean canBook(Cargo cargo, Voyage voyage) {
double maxBooking = voyage.getСapacity() * 1.1;
if (
voyage.getBookedCargoSize() + cargo. getSize() > maxBooking
)
return false;
...
}
public boolean сanBook(Cargo cargo, Voyage voyage) {
if (!overbookingPolicy.isAllowed(cargo, voyage))
return false;
...
}
DDD делает концепции явными

19.

Практ
ики
Прин
ципы
Стратегич
еские
Паттерн
ы
Тактическ
ие

20.

Основное в DDD — это тактические паттерны
DDD — это фреймворк (каркас)
DDD — это серебряная пуля

21.

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

22.

Модель – система абстракций,
описывающая некоторые аспекты
предметной области и
используемая для решения задач,
связанных с описываемой
предметной областью
Упрощенное (но, не примитивное!)
приближение реальности
Модель не может быть правильной
или не правильной, она может
быть более или менее полезной

23.

Пространство задач
(the problem space)
Пространство решений
(the solution space)

24.

Полезность
Согласованность
Красота
Лаконичность

25.

Модель закладывает не только статику, но и поведение
Модель — это ментальный образ, существующий в
представлениях команды и представляемый кодом,
диаграммами и т. п.
Модель имеет
удобный вид для реализации (участие программистов)
отображает предметную область (доменные
специалисты)
Бизнес правила столь же важны для модели, сколь и
сущности в нее входящие
Сущности и бизнес правила должны трассироваться в код
Критерий - код должен быть понятен бизнес экспертам при
определенном объяснении разработчиками

26.

Не пытайтесь отобразить реальность дословно
Вам нужна не полная модель реальности, а полезная модель
Как программисты хлеб пекли
Моделируйте только значимые аспекты реальности
Абстрагирование
Модель имеет значение только здесь и сейчас
Не пытайтесь решить все задачи одновременно, модель
нужна на очередной итерации
Выявляйте термины
Ограничивайте использование абстракций
Используйте в коде абстракции подходящего уровня
Абстрагируйте поведение а не реализации
Моделируйте в коде сразу и постоянно
Не останавливайтесь на первой хорошей идее

27.

Излишне детализированная диаграмма не
дает пользы, мешает пониманию модели
Маленькие диаграммы теряют смысл без
вербального описания и требуют объяснения
Детальные диаграммы - дублирование кода
Проблема поддержки
Использовать ли UML ?

28.

Зачем в документации информация, которую
можно найти в коде ?
Зачем в документации информация, которую
можно сгенерировать по коду ?
Документация должно способствовать
коммуникации
Каждая команда решает для себя насколько
важна документация
Документ должен быть актуален на
протяжении проекта

29.

Если не использовать словесное общение
— теряется знание о модели
Диаграммы не могут вытеснить общение !

30.

Должно быть нечто связывающее модели
Основное
представление
предметной области
Аналитическая модель
(Бизнес модель)
Модель кода
Единый язык
ubiquitous language
Доменный эксперт не заботится о разработке
(так как не понимает ее)

31.

Если модель не представлена в коде, понять поведение бывает очень сложно
Что представляет этот код ?
for (int p = 0; p < 12; p++) {
CString str_SV, str_SA;
sec_V[p] = atoi(str_SV);
sec_A[p] = atof(str_SA);
P2[p] = sec_V[p] * sec_A[p];
P1 += P2[p] / 0.85;
}
Алгоритм расчета мощности
трансформатора

32.

Анемия
Anemic Domain Model [Fowler, Anemic]
Повсеместная анемия
Anemia everywhere (благодаря JavaBean)
Потеря памяти (Memory loss)
Семантический разрыв
Representation [Semantic] Gap
Low Representation Gap
High Representation Gap

33.

Стандарт JavaBean
Концепция POJO (POCO, PORO)
Поддержка различными каркасами
Повсеместное распространение анемии

34.

Какое поведение
предполагается для этого
класса ?

35.

Employees can capture Annual and Study leave
There are various rules around capturing leave

36.

There is a new Sick Leave Type
Sick leave can only be assigned if a sick note is
attached
All leave entries requires a document?

37.

Отличие нашего представления
модели от его выражения в коде
Low Representation Gap
Имя концепта в коде отличается
от имени, применяемом в
бизнесе
Cat
Lion

38.

High Representation Gap
Design
«interface»
EntityBean
«interface»
EJBHome
Cat
«interface»
CatHome
«interface»
EJBObject
«interface»
Cat
«interface»
CatEJB

39.