SlideShare a Scribd company logo
1 of 18
Предметно-ориентированное
проектирование
Привет, Эванс
Что это вообще такое?
Вроде бы всего лишь один из шаблонов реализации бизнес-
логики!
Но не только..
Пример того, как следует выделить предметную область в
программном обеспечении, для того, чтобы проще преодолевать
сложности, частые изменения, проблемы коммуникации и прочие
недуги предметной области.
Не отменяет практики
DDD – лишь дополнение
- ООП
- Паттерны
- SOLID, KISS, DRY, …
- TDD
- IoC
- ORM
Где это нужно?
Не надо использовать DDD везде!
Хорошо подходит для Enterprise
- длинный жизненный цикл
- большое количество сущностей со сложными
«взаимоотношениями»
- эволюция бизнес-модели
2 стороны DDD
Тактика
- сущность
- объект-значение
- сервис
- событие
- агрегат
- фабрика
- хранилище
Стратегия
- единый язык
- предметная область
- предметная подобласть
- смысловое ядро
- ограниченный контекст
- карта контекстов
Единый язык
Язык созданный и понимаемый ВСЕМИ участниками проекта –
экспертами, разработчиками, бизнес-аналитиками, а то и
заказчиками.
Каждый участник проекта использует в своей работе именно этот
язык – и в коде, и в документации и в общении.
Единый язык (честно украденный пример)
«Медсестра назначает вакцину от гриппа пациенту в стандартной дозе»
patient.SetShotType(ShotTypes.Flu);
patient.SetDose(dose);
patient.SetNurse(nurse);
patient.GiveFluShot();
Vaccine vaccine = Vaccines.StandartAdultFluDose();
nurse.AdministerFluVaccine(patient, vaccine);
Ограниченный контекст
В рамках предметной области смысл определенного термина или
фразы может сильно отличаться.
Ограниченный контекст - некая граница, в пределах которой
понятия единого языка имеют вполне конкретное контекстное
значение.
Ограниченный контекст (пример)
Понятие «Счет» в разных предметных областях
Банковские услуги – счет клиента
Партия в теннис – счет матча
Предметная область, подобласть,
смысловое ядро
Предметная область – это то, что делает организация, и среда, в
которой она это делает. Смысл бизнеса, вся его аутентичность.
Это и есть DOMAIN – первая D в DDD.
Смысловое ядро – подобласть, имеющая первостепенное
значение.
Пространство задач и пространство
решений
Пространство задач – части предметной области, необходимые для
создания смыслового ядра (т.е. само ядро + какие-либо
предметные подобласти).
Пространство решений – один или несколько ограниченных
контекстов. Разработанный ограниченный контекст – это по сути
реализация решения пространства задач.
Идеальный вариант – однозначное соответствие между
подобластями и контекстами, т .е. между задачами и решениями.
Карта контекстов
Отображение пространства решений, в котором находится команда.
Набор ограниченных контекстов и связей между ними:
- Partnership
- Shared kernel
- Customer-supplier development
- Conformist
- Anticorruption layer
- Open host service
- Published language
- Separate ways
- Big ball of mud
Сущность
Понятие предметной области, которое является уникальным и
отличным от всех других объектов в системе.
То, что имеет свою идентичность/индивидуальность, которая
связана с ней на протяжении всего существования.
Объект-значение
Объект, для которого не важна его индивидуальность.
Объект, который полностью определяется своими атрибутами.
- измеряет, описывает объекты предметной области
- можно считать неизменяемым
- моделирует нечто концептуально целое
Сервис
Выполняет действия, которые нельзя отнести к какой-то
конкретной сущности или объекту-значению.
- Операция не принадлежит ни одному из объектов предметной
области
- Операция выполняется над различными объектами предметной
области
Злоупотребление приводит к «анемичной модели предметной
области».
Агрегат
Кластер из объектов сущностей или значений.
Агрегаты рассматриваются как единое целое с точки зрения
изменения данных.
У агрегата есть корень агрегации. Все обращения к агрегату
должны происходить через него.
Фабрика
Некоторые агрегаты или сущности могут быть достаточно
сложными.
Сложный объект не может создавать сам себя посредством
конструктора.
Двигатель автомобиля собирается либо механиком, либо роботом,
но он никак не должен собираться сам по себе.
Хранилище
Область, которая предназначена для безопасного хранения
помещенных в нее элементов.
Каждый агрегат, предполагающий постоянное хранение, должен
иметь свое хранилище.

More Related Content

Similar to Экскурс в Domain-driven design

03 т сервис
03 т сервис03 т сервис
03 т сервис
Goudron1979
 
документирование долгоживущих веб проектов. г. белогорцев. зал 3
документирование долгоживущих веб проектов. г. белогорцев. зал 3документирование долгоживущих веб проектов. г. белогорцев. зал 3
документирование долгоживущих веб проектов. г. белогорцев. зал 3
rit2011
 
Ms SharePoint workspace for Project Management
Ms SharePoint workspace for Project ManagementMs SharePoint workspace for Project Management
Ms SharePoint workspace for Project Management
Vladimir Ivanov
 

Similar to Экскурс в Domain-driven design (20)

"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ... "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Как и зачем можно создать DSL на Python
Как и зачем можно создать DSL на PythonКак и зачем можно создать DSL на Python
Как и зачем можно создать DSL на Python
 
УИТП 1 темы 1 - 3.ppt aRCHIMATE IN RUSSIAN
УИТП 1 темы 1 - 3.ppt aRCHIMATE IN RUSSIANУИТП 1 темы 1 - 3.ppt aRCHIMATE IN RUSSIAN
УИТП 1 темы 1 - 3.ppt aRCHIMATE IN RUSSIAN
 
CompanyMedia4You - Нити управления
CompanyMedia4You - Нити управленияCompanyMedia4You - Нити управления
CompanyMedia4You - Нити управления
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требований
 
DDD requirements AnalystDays-2014 Tsepkov
DDD requirements AnalystDays-2014 TsepkovDDD requirements AnalystDays-2014 Tsepkov
DDD requirements AnalystDays-2014 Tsepkov
 
DDD - модель вместо требований
DDD - модель вместо требованийDDD - модель вместо требований
DDD - модель вместо требований
 
Ddd softwarepeople-2013-tsepkov
Ddd softwarepeople-2013-tsepkovDdd softwarepeople-2013-tsepkov
Ddd softwarepeople-2013-tsepkov
 
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
 
Java Framework for Multi-agent Systems
Java Framework for Multi-agent SystemsJava Framework for Multi-agent Systems
Java Framework for Multi-agent Systems
 
Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01
 
03 т сервис
03 т сервис03 т сервис
03 т сервис
 
Базовый инструментарий аналитика. Методы и техники используемые в инженерии т...
Базовый инструментарий аналитика. Методы и техники используемые в инженерии т...Базовый инструментарий аналитика. Методы и техники используемые в инженерии т...
Базовый инструментарий аналитика. Методы и техники используемые в инженерии т...
 
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуреCodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
 
Agile в больших и очень больших проектах
Agile в больших и очень больших проектахAgile в больших и очень больших проектах
Agile в больших и очень больших проектах
 
документирование долгоживущих веб проектов. г. белогорцев. зал 3
документирование долгоживущих веб проектов. г. белогорцев. зал 3документирование долгоживущих веб проектов. г. белогорцев. зал 3
документирование долгоживущих веб проектов. г. белогорцев. зал 3
 
Ms SharePoint workspace for Project Management
Ms SharePoint workspace for Project ManagementMs SharePoint workspace for Project Management
Ms SharePoint workspace for Project Management
 
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПОЕвгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
 

More from Tados

More from Tados (6)

Дарелл Хафф «Как лгать при помощи статистики»
Дарелл Хафф «Как лгать при помощи статистики» Дарелл Хафф «Как лгать при помощи статистики»
Дарелл Хафф «Как лгать при помощи статистики»
 
Дэвид Льюис «Нейромаркетинг в действии»
Дэвид Льюис «Нейромаркетинг в действии»Дэвид Льюис «Нейромаркетинг в действии»
Дэвид Льюис «Нейромаркетинг в действии»
 
GIT: что внутри, и как это работает?
GIT: что внутри, и как это работает?GIT: что внутри, и как это работает?
GIT: что внутри, и как это работает?
 
Docker в хозяйстве и быту
Docker в хозяйстве и бытуDocker в хозяйстве и быту
Docker в хозяйстве и быту
 
О компании Tados: цифры и факты на 2017 год
О компании Tados: цифры и факты на 2017 годО компании Tados: цифры и факты на 2017 год
О компании Tados: цифры и факты на 2017 год
 
Чистый код: создание, анализ и рефакторинг
Чистый код: создание, анализ и рефакторингЧистый код: создание, анализ и рефакторинг
Чистый код: создание, анализ и рефакторинг
 

Экскурс в Domain-driven design

  • 2. Что это вообще такое? Вроде бы всего лишь один из шаблонов реализации бизнес- логики! Но не только.. Пример того, как следует выделить предметную область в программном обеспечении, для того, чтобы проще преодолевать сложности, частые изменения, проблемы коммуникации и прочие недуги предметной области.
  • 3. Не отменяет практики DDD – лишь дополнение - ООП - Паттерны - SOLID, KISS, DRY, … - TDD - IoC - ORM
  • 4. Где это нужно? Не надо использовать DDD везде! Хорошо подходит для Enterprise - длинный жизненный цикл - большое количество сущностей со сложными «взаимоотношениями» - эволюция бизнес-модели
  • 5. 2 стороны DDD Тактика - сущность - объект-значение - сервис - событие - агрегат - фабрика - хранилище Стратегия - единый язык - предметная область - предметная подобласть - смысловое ядро - ограниченный контекст - карта контекстов
  • 6. Единый язык Язык созданный и понимаемый ВСЕМИ участниками проекта – экспертами, разработчиками, бизнес-аналитиками, а то и заказчиками. Каждый участник проекта использует в своей работе именно этот язык – и в коде, и в документации и в общении.
  • 7. Единый язык (честно украденный пример) «Медсестра назначает вакцину от гриппа пациенту в стандартной дозе» patient.SetShotType(ShotTypes.Flu); patient.SetDose(dose); patient.SetNurse(nurse); patient.GiveFluShot(); Vaccine vaccine = Vaccines.StandartAdultFluDose(); nurse.AdministerFluVaccine(patient, vaccine);
  • 8. Ограниченный контекст В рамках предметной области смысл определенного термина или фразы может сильно отличаться. Ограниченный контекст - некая граница, в пределах которой понятия единого языка имеют вполне конкретное контекстное значение.
  • 9. Ограниченный контекст (пример) Понятие «Счет» в разных предметных областях Банковские услуги – счет клиента Партия в теннис – счет матча
  • 10. Предметная область, подобласть, смысловое ядро Предметная область – это то, что делает организация, и среда, в которой она это делает. Смысл бизнеса, вся его аутентичность. Это и есть DOMAIN – первая D в DDD. Смысловое ядро – подобласть, имеющая первостепенное значение.
  • 11. Пространство задач и пространство решений Пространство задач – части предметной области, необходимые для создания смыслового ядра (т.е. само ядро + какие-либо предметные подобласти). Пространство решений – один или несколько ограниченных контекстов. Разработанный ограниченный контекст – это по сути реализация решения пространства задач. Идеальный вариант – однозначное соответствие между подобластями и контекстами, т .е. между задачами и решениями.
  • 12. Карта контекстов Отображение пространства решений, в котором находится команда. Набор ограниченных контекстов и связей между ними: - Partnership - Shared kernel - Customer-supplier development - Conformist - Anticorruption layer - Open host service - Published language - Separate ways - Big ball of mud
  • 13. Сущность Понятие предметной области, которое является уникальным и отличным от всех других объектов в системе. То, что имеет свою идентичность/индивидуальность, которая связана с ней на протяжении всего существования.
  • 14. Объект-значение Объект, для которого не важна его индивидуальность. Объект, который полностью определяется своими атрибутами. - измеряет, описывает объекты предметной области - можно считать неизменяемым - моделирует нечто концептуально целое
  • 15. Сервис Выполняет действия, которые нельзя отнести к какой-то конкретной сущности или объекту-значению. - Операция не принадлежит ни одному из объектов предметной области - Операция выполняется над различными объектами предметной области Злоупотребление приводит к «анемичной модели предметной области».
  • 16. Агрегат Кластер из объектов сущностей или значений. Агрегаты рассматриваются как единое целое с точки зрения изменения данных. У агрегата есть корень агрегации. Все обращения к агрегату должны происходить через него.
  • 17. Фабрика Некоторые агрегаты или сущности могут быть достаточно сложными. Сложный объект не может создавать сам себя посредством конструктора. Двигатель автомобиля собирается либо механиком, либо роботом, но он никак не должен собираться сам по себе.
  • 18. Хранилище Область, которая предназначена для безопасного хранения помещенных в нее элементов. Каждый агрегат, предполагающий постоянное хранение, должен иметь свое хранилище.