Domain Driven Design в условиях разработки распределенных приложений

Николай Гребнев

1

2

Содержание• Что такое DDD?• Распределенные приложения• Проблемы DDD в распределенных

приложениях• Как быть?• Принимаем решение• Подводим итоги

3

ЧТО ТАКОЕ DDD?

4

DDD – DataDisplayDebugger?

5

DDD – Domain Driven Design!

Domain Driven Design

6

7

Domain Driven DesignПроектирование по модели – проектирование архитектуры, при котором соблюдается максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели (Эрик Эванс)

8

Domain Driven Design

9

Модель программы

10

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

11

Модель программы

• DataSet• DataReader • Command• DataAdapter• Connection• И т. д.

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

• Книга• Автор• Издатель• Читатель• И т. д.

12

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

13

Domain Driven DesignDDD – проекция языка предметной области на объектно ориентированный язык программирования

14

Почему DDD?• Эффективный способ борьбы со

сложностью• Единый язык

• Низкая стоимость разработки и сопровождения

15

Почему DDD в Agile?• Расстояние между заказчиком и

разработчиком невелико• Заказчик и разработчик разговаривают на

одном языке• Итеративная разработка – постепенное

изменение модели

16

ORM (Object-relational mapping)ORM – технология программирования для конвертации данных между несовместимыми типами систем в объектно-ориентированные языки

17

ORM

ORM ≠ DDD

18

19

Архитектурные стили при работе с ORM

20

Rich VS Anemic

21

Rich

+Бизнес-логика()

-Данные

Класс1

+Бизнес-логика()

-Данные

Класс2

+Бизнес-логика()

-Данные

Класс3

*

*

*

*

22

Anemic

23

Anemic?

ORM?

24

Rich!

25

РАСПРЕДЕЛЕННЫЕ ПРИЛОЖЕНИЯ

26

Шаблоны распределенных архитектур• Клиент-Сервер• 3-х звенная (многозвенная) архитектура• SOA• Enterprise Service Bus

27

Клиент-Сервер

Клиент БД

28

3-х звенная архитектура

Сервер приложений БД Клиент

29

SOA

Сервис 1

Сервис 2 Сервис 3

30

Enterprise Service Bus

ESB

Система 1

Система 2 Система 3

31

Почему распределенная архитектура?

• Безопасность• Эффективность• Совместная работа

32

DDD В РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЯХ

33

Клиент

Клиент-Сервер

БД ORM Доменная модель

Проблемы?

34

Нет проблем!

35

ORM БД Доменная

модель

36

3-х звенная архитектура

Сервер приложений

БД ORM Доменная модель сервера

Клиент

Доменная модель клиента

Проблемы?

37

38

Проблемы• Как?– Построить взаимодействие с сервером

– Преобразовать данные в доменную модель на клиенте

?Доменная

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

?

39

SOAСервис 1

БД ORM Доменная модель 1

Сервис 2

Доменная модель 2

Сервис 3

Доменная модель 3

Проблемы?

40

41

Проблемы• Как?– Построить взаимодействие другими сервисами

– Преобразовать данные в локальную доменную модель

?

Доменная модель

?

42

Проблемы• Как? – Сочетать использование ORM и работу с

другими сервисами?

Доменная модель сервиса

БД ORM

43

Enterprise Service Bus

Система 2

Доменная модель 2

Система 3

Доменная модель 3

Система 1

БД ORM Доменная модель 1

ESB

Проблемы?

44

45

Проблемы• Как?– Построить взаимодействие с шиной

– Преобразовать данные из шины в доменную модель

ESB ?

ESB ?Доменная

модель системы

46

Проблемы• Как? – Сочетать использование ORM и работу с шиной

Доменная модель сервиса

БД ORM

ESB

47

Проблемы в DDD в распределенных приложениях

• Взаимодействие с удаленными источниками данных

?

48

Проблемы в DDD в распределенных приложения

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

Данные ?Доменная

модель системы

Распределенная архитектура вносит в модель объекты

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

Соединение

Сервис временно недоступен

Данные по запросу

50

Проблемы в DDD в распределенных приложения

• Сочетание различных источников данных

Доменная модель

Данные

Данные

51

Развитие DDD

2002 год 2003 год 2008 год

52

Причины• Отсутствие шаблонов для

удаленного взаимодействия

• Отсутствие готовых инструментальных средств

53

КАК БЫТЬ?

Шаблоны удаленного взаимодействия

55

RPC (Remote Procedure Call)• .NET Remoting• CORBA• WCF• и т. д.

Почему нет?

56

57

Почему нет?

• Доменные модели разные

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

выше стоимости локалького

Data Transfer Object

59

DTOДоменная модель 1

Доменная модель 2

60

DTOДоменная модель

Инструменты

62

Что делать?Логика

преобразования данных и удаленного

взаимодействия

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

63

Что делать?

Разработать инструментарий

64

ПРИНИМАЕМ РЕШЕНИЕ

65

Клиент-сервер

• Множество инструментов и платформ

• Готовые архитектурные шаблоны

• DDD – выгодно

66

3-х звенная архитектура• Тонкий клиент – см. клиент-сервер• Толстый клиент:– Мало логики – не использовать DDD на клиенте– Средне логики – помещать инфраструктурный

код в доменную модель– Много логики – разработать свой слой

преобразования данных

67

SOA и ESB• Удаленного взаимодействия немного –

поместить логику преобразования данных в доменную модель

• Иначе – разработать свой слой преобразования данных

68

ПОДВОДИМ ИТОГИ

Распределенная архитектура – данность

70

Что нам дает DDD• Эффективный способ борьбы со

сложностью• Единый язык

• Низкая стоимость разработки и сопровождения

Но есть проблемы!

72

Так что же делать?• Оценить:– Сложность доменной модели– Необходимость сильно распределенной

архитектуры– Стоимость разработки собственных

инструментов

Вопросы?

Докладчик: Николай Гребневe-mail: ngrebnev@gmail.comhttp://www.slideshare.net/ngrebnev/domain-driven-design-6988494

73