Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений. Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD). Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы: - Стоит ли использовать DDD при разработке распределенных приложений? - Как использовать DDD при использовании различных архитектурных стилей? - Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области? - Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?

1. DomainDrivenDesign в условиях разработки распределенных приложений Николай Гребнев 1

2. Содержание Что такое DDD? Распределенные приложения Проблемы DDD в распределенных приложениях Как быть? Принимаем решение Подводим итоги 2

3. Что такое DDD? 3

4. DDD – DataDisplayDebugger? 4

5. DDD – Domain Driven Design! 5

6. Domain Driven Design 6

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

8. Domain Driven Design 8

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

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

11. Модель программы Модель предметной области DataSet DataReader Command DataAdapter Connection И т. д. Книга Автор Издатель Читатель И т. д. 11

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

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

14. Почему DDD? Эффективный способ борьбы со сложностью Единый язык Низкая стоимость разработки и сопровождения 14

15. Почему DDD в Agile? Расстояние между заказчиком и разработчиком невелико Заказчик и разработчик разговаривают на одном языке Итеративная разработка – постепенное изменение модели 15

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

17. ORM 17

18. ORM ≠ DDD 18

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

20. Rich VS Anemic 20

21. Rich 21

22. Anemic 22

23. Anemic? 23 ORM?

24. Rich! 24

25. Распределенные приложения 25

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

27. Клиент-Сервер БД Клиент 27

28. 3-х звенная архитектура БД Сервер приложений Клиент 28

29. SOA Сервис 1 29 Сервис 2 Сервис 3

30. Enterprise Service Bus Система 1 Система 2 Система 3 ESB 30

31. Почему распределенная архитектура? Безопасность Эффективность Совместная работа 31

32. DDD в распределенных приложениях 32

33. Клиент Клиент-Сервер БД ORM Доменная модель 33

34. Проблемы? 34

35. Нет проблем! БД Доменная модель ORM 35

36. 3-х звенная архитектура Сервер приложений Клиент БД ORM Доменная модель клиента Доменная модель сервера 36

37. Проблемы? 37

38. Проблемы Как? Построить взаимодействие с сервером Преобразовать данные в доменную модель на клиенте 38 ? Доменная модель клиента ?

39. SOA ORM Доменная модель 2 Доменная модель 3 Доменная модель 1 БД Сервис 1 Сервис 2 Сервис 3 39

40. Проблемы? 40

41. Проблемы Как? Построить взаимодействие другими сервисами Преобразовать данные в локальную доменную модель 41 ? Доменная модель ?

42. Проблемы Как? Сочетать использование ORM и работу с другими сервисами? 42 БД Доменная модельсервиса ORM

43. Enterprise Service Bus Доменная модель 2 Доменная модель 3 ORM Доменная модель 1 БД Система 3 Система 2 Система 1 ESB 43

44. Проблемы? 44

45. Проблемы Как? Построить взаимодействие с шиной Преобразовать данные из шины в доменную модель 45 ESB ? ESB Доменная модель системы ?

46. Проблемы Как? Сочетать использование ORM и работу с шиной 46 БД Доменная модельсервиса ORM ESB

47. Проблемы в DDD в распределенных приложениях Взаимодействие с удаленными источниками данных 47 ?

48. Проблемы в DDD в распределенных приложения Преобразование данных из удаленных источников в доменную модель 48 Данные Доменная модель системы ?

49. Сервис временно недоступен Соединение Распределенная архитектура вносит в модель объекты отсутствующие в предметной области Данные по запросу

50. Проблемы в DDD в распределенных приложения Сочетание различных источников данных 50 Доменная модель Данные Данные

51. Развитие DDD 51 2002 год 2003 год 2008 год

52. Причины Отсутствие шаблонов для удаленного взаимодействия Отсутствие готовых инструментальных средств 52

53. Как быть? 53

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

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

56. Почему нет? 56

57. Почему нет? Доменные модели разные Стоимость удаленного вызова на порядки выше стоимости локалького 57

58. Data Transfer Object

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

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

61. Инструменты

62. Что делать? 62 Логика преобразования данных и удаленного взаимодействия Модель предметной области

63. Что делать? Разработать инструментарий 63

64. Принимаем решение 64

65. Клиент-сервер Множество инструментов и платформ Готовые архитектурные шаблоны DDD – выгодно 65

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

67. SOA и ESB Удаленного взаимодействия немного – поместить логику преобразования данных в доменную модель Иначе – разработать свой слой преобразования данных 67

68. Подводим итоги 68

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

70. Что нам дает DDD Эффективный способ борьбы со сложностью Единый язык Низкая стоимость разработки и сопровождения 70

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

72. Так что же делать? Оценить: Сложность доменной модели Необходимость сильно распределенной архитектуры Стоимость разработки собственных инструментов 72

73. Вопросы? Докладчик: Николай Гребнев e-mail: ngrebnev@gmail.com http://www.slideshare.net/ngrebnev/domain-driven-design-6988494 73