|
Персональные инструменты |
![]() |
||
|
![]() |
![]() DDD: проблемы и решения в отражении модели предметной области в код (Максим Цепков на Software People 2013) — различия между версиямиМатериал из CustisWiki
Текущая версия на 12:36, 13 февраля 2014Доклад был сделан на конференции SoftwarePeople-2013. Видео
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/64288585?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe> Скачать → на странице видео на vimeo, кнопка «Download» Краткое содержание докладаDomain Driven Design (DDD) — активно развивающийся подход к разработке приложений в сложных предметных областях, предложенный Эриком Эвансом. Единый язык (ubiquitous launguage) позволяет описать единую модель. Domain Driven Design (DDD) — эффективный подход к разработке приложений в сложных предметных областях, предложенный Эриком Эвансом и активно развиваемый в мире. Разработка для проекта Единого языка (ubiquitous launguage) обеспечивает эффективные коммуникации между всеми участниками проекта а, главное, позволяет описать на нем единую модель, понятную всем участникам проекта, согласуемую с заказчиком и используемую для реализации приложения. Для реализации приложения при классическим применении DDD используется отражение модели в код приложения на основе шаблонов Domain model и Rich objects, при этом каждый класс в коде непосредственно соответствует объекту модели. Однако, с таким подходом связаны определенные проблемы в процессе разработки:
Для преодоления этих проблем мы применяем особый способ отображения модели предметной области в код, который назвали «технологические рельсы» проекта. Это набор типовых решений – шаблонов и правил их применения, в которых сосредоточены технические особенности создаваемой ИТ-системы. «Технологические рельсы» включают: платформы и фреймворки, а также способы их организации в единое приложение, инфраструктурные библиотеки, способы реализации документооборота, преобразования в код типовых конструкций бизнес-логики (включая учетную модель), способы корректного изменения элементов модели, а также типовые интерфейсы для определенных объектов модели. Важно, что «технологические рельсы» выделяют и используют типовые конструкции, использование которых не требует дополнительного проектирования и описания в модели. Будучи понятными и согласованными со всеми участникам проекта, они (конструкции) приобретают статус терминов единого языка, описывающих сложные объекты. Поэтому описание модели становится более компактным, а технические подробности уходят из него в описание технологических рельсов. Естественно, далеко не все части системы могут быть построены на основе типовых решений, и в этом случае необходимо техническое проектирование в рамках конкретного функционального блока. Однако, по нашему опыту, это касается относительно малой части системы, хотя и наиболее важной. Таким образом, применение этого подхода позволяет сосредоточиться на проектировании именно сложных и существенных фрагментов системы. С помощью технологических рельсов хорошо отделяется техническая составляющая решения, которая обычно согласуется с техническими специалистами заказчика, а не с бизнес-пользователями. Такой подход также четко разграничивает ответственность между аналитиками и архитекторами: первые отвечают за модель, а вторые — за «технологические рельсы». Аналитик, хорошо понимающий типовые решения и границы их применения, может быстро оценить сложность реализации требований заказчика. Это дает большое преимущество в условиях динамически меняющихся проектных требований. «Технологические рельсы» проекта обеспечивают успешное применение DDD, поскольку:
Все это обеспечивает эффективную разработку и является залогом долгого и успешного развития ИТ-системы, уже находящейся в эксплуатации. ПрезентацияОб автореМаксим Цепков – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Закончил с отличием МФТИ (1991), имеет авторские свидетельства. Профессиональные интересы – создание архитектуры корпоративных и банковских информационных систем, поиск баланса между общими архитектурными подходами и реализацией специфических требований заказных проектов. Максим активно участвует в развитии внутренних процессов и совершенствовании практик применения гибких методологий разработки и коллективного проектирования в CUSTIS.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||||||||||
![]() |
![]() |