РУС | EN

14 июня(пятница) 2013 Москва

Телефон: +7 (499) 403-10-11 (многокан)
E-mail: 2013@devconf.ru

Архив 2013 года - актуальная информация тут

Domain Driven Design on Rails

Николай Рыжиков, СПб

Team lead of Hospital Information System "MedClient"
Choice Hospital Systems (US)

Доклад(45 мин)    Презентация (pptx, 1.3 Mb)

В процессе проектирования и разработки системы программисты, аналитики и заказчики так или иначе создают “ментальную” модель приложения.
У разных участников команды модель в общем виде будет отличаться.
Эти смысловые различия могут привести к серьезным проблемам и недопониманию в процессе разработки, порой даже к преждевременному старению системы и гибели проекта.
Особенно остро проблема “модельной шизофрении” (взаимопонимания) может встать в проектах со сложной предметной областью.
Как быть в таком случае?
Как попытаться гармонизировать эти разные модели одной системы (вылечить систему и процесс ее разработки)?
На эти вопросы пытается ответить методология DDD (Domain Driven Design).
DDD делает модель явной, а работу над этой моделью ставит на первое место в процессе разработки всей системы.
Ruby on Rails & Agile как добрая почва для DDD.

Подробно:
В процессе проектирования и разработки системы программисты, аналитики и заказчики так или иначе создают “ментальную” модель приложения. Эта модель служит им для принятия решений, чем система будет являться и как она будет устроена, и даже как она будет развиваться.

У разных участников команды модель в общем виде будет отличаться, поскольку они смотрят на систему под разными углами и вырабатывают эту модель по-разному. Эти смысловые различия могут привести к серьезным проблемам и недопониманию в процессе разработки, порой даже к преждевременному старению системы и гибели проекта.

Особенно остро проблема “модельной шизофрении” (взаимопонимания) может встать в проектах со сложной предметной областью. Cложная предметная область это такая область деятельности, для понимания которой вам необходим объем знаний, сравнимый с тем, который вы уже за многие годы накопили по программированию, т. е. в неадаптированном виде он уже не поместится в вашу голову за осмысленное время.

Как быть в таком случае?
Как попытаться гармонизировать эти разные модели одной системы (вылечить систему и процесс ее разработки)?
Как хоть как-то совладать со сложной предметной областью и не потерять остатки смысла?

На эти вопросы пытается ответить методология DDD (Domain Driven Design).

DDD делает модель явной, а работу над этой моделью ставит на первое место в процессе разработки всей системы.

Все участники команды (программисты, аналитики, эксперты, пользователи) разрабатывают единую модель приложения, основным и живым результатом этого процесса является Ubiquitous Language, предметный язык, на котором все начинают общатся. Этот язык реализуется в общении с экспертами, аналитиками и программистами, получает свое отражение в коде.


План.
Краткое введение в DDD и основные понятия (Ubiquitous Language, Context, Context Map)
Пример
Ruby on Rails & Agile как добрая почва для DDD



Программа конференции