----

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)»

Этот доклад был рассказан на конференции AnalystDays – 2014. Он сделан на основе одноименного доклада на HappyDev – 2013, при этом дополнительно рассмотрены варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD.

Доклад на сайте конференции
Презентация на Slideshare
Видео на vimeo

Аннотация

Есть много подходов к работе с требованиями — user story, use case и т. д., — но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

Domain-Driven Design — подход, превращающий предметную область из «темного леса» в прозрачную систему. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками. Это позволяет модели, описанной на этом языке, заменить традиционные требования, которые служат лишь для построения модели, а затем теряют актуальность. Такой подход качественно упрощает процесс проектирования и значительно снижает риски IT-проектов, позволяя бизнес-специалистам заказчика полноценно верифицировать модель системы. А в процессе эксплуатации модель обеспечивает возможность эффективного развития системы на протяжении многих лет вслед за развитием бизнеса заказчика.

Annotation

There are many methods to develop requirements (user story, use case and so on), but all of them mainly describe behavioural aspects. But how to work in the sphere of complex business requirements where objects change their behaviour as the context may admit?

Domain-Driven Design (DDD) is an approach that allows to create clear and clean vision of domain area. Ubiquitous language gives ground for communication between customers, analytics, developers, testers and end-users. And we can use models developed in this language instead of traditional requirements, which are used only to build models in this process, and then they lost their actuality. This approach significantly simplifies design process and reduces risks in complex IT-projects enabling business professionals to fully verify Models. And then, while in operation, Models allow to develop and expand software system efficiently for many years following changes of customer’s business processes.