DDD: проблемы и решения в отражении модели предметной области в код (Максим Цепков на Software People 2013)

Короткая ссылка: DDD problem and solving

Ссылки сюда (3) →

Доклад был сделан на конференции SoftwarePeople-2013.

Видео

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/64288585?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>

Краткое содержание доклада

Domain Driven Design (DDD) — активно развивающийся подход к разработке приложений в сложных предметных областях, предложенный Эриком Эвансом. Единый язык (ubiquitous launguage) позволяет описать единую модель.

Domain Driven Design (DDD) — эффективный подход к разработке приложений в сложных предметных областях, предложенный Эриком Эвансом и активно развиваемый в мире. Разработка для проекта Единого языка (ubiquitous launguage) обеспечивает эффективные коммуникации между всеми участниками проекта а, главное, позволяет описать на нем единую модель, понятную всем участникам проекта, согласуемую с заказчиком и используемую для реализации приложения.

Для реализации приложения при классическим применении DDD используется отражение модели в код приложения на основе шаблонов Domain model и Rich objects, при этом каждый класс в коде непосредственно соответствует объекту модели. Однако, с таким подходом связаны определенные проблемы в процессе разработки:

• Сложные бизнес-объекты модели, которые включены в документооборот, бизнес-алгоритмы, внешний обмен, печать и другие, в реализации порождают большие и разнородные классы, что противоречит принципам ООП.
• Сложные взаимосвязанные бизнес-объекты порождают сильно связанную ИТ-систему, для которой тяжело создавать изолированные автоматические тесты.
• Имеет место обратное влияние технологий разработки на модель: многие распространенные фреймворки ограничивают использование в ней сложных бизнес-объектов.
• Требование DDD поддерживать соответствие модели и разрабатываемого кода приводит к тому, что технические классы и другие аспекты решений, возникающие при реализации, также получают свое отражение в модели. Это усложняет ее понимание и согласование с заказчиком.
• Классический DDD-подход ограничивается моделью предметной области, оставляя в стороне интерфейсы пользователя.
• Распространенные языки программирования (Java, C#) являются преимущественно объектными, что побуждает создавать только объектные модели, хотя они плохо подходят для описания некоторых бизнес-областей (например, для учета).

Для преодоления этих проблем мы применяем особый способ отображения модели предметной области в код, который назвали «технологические рельсы» проекта. Это набор типовых решений – шаблонов и правил их применения, в которых сосредоточены технические особенности создаваемой ИТ-системы.

«Технологические рельсы» включают: платформы и фреймворки, а также способы их организации в единое приложение, инфраструктурные библиотеки, способы реализации документооборота, преобразования в код типовых конструкций бизнес-логики (включая учетную модель), способы корректного изменения элементов модели, а также типовые интерфейсы для определенных объектов модели.

Важно, что «технологические рельсы» выделяют и используют типовые конструкции, использование которых не требует дополнительного проектирования и описания в модели. Будучи понятными и согласованными со всеми участникам проекта, они (конструкции) приобретают статус терминов единого языка, описывающих сложные объекты. Поэтому описание модели становится более компактным, а технические подробности уходят из него в описание технологических рельсов. Естественно, далеко не все части системы могут быть построены на основе типовых решений, и в этом случае необходимо техническое проектирование в рамках конкретного функционального блока. Однако, по нашему опыту, это касается относительно малой части системы, хотя и наиболее важной. Таким образом, применение этого подхода позволяет сосредоточиться на проектировании именно сложных и существенных фрагментов системы.

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

«Технологические рельсы» проекта обеспечивают успешное применение DDD, поскольку:

• сочетают описание модели в понятных заказчику терминах со сложными техническими решениями при реализации;
• помогают соблюдать ограничения, накладываемые фреймворками, платформами и библиотеками на организацию программного кода, поддерживают их совместную работу и однородность решений в рамках проекта.

Все это обеспечивает эффективную разработку и является залогом долгого и успешного развития ИТ-системы, уже находящейся в эксплуатации.

Презентация

Об авторе

Максим Цепков – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Закончил с отличием МФТИ (1991), имеет авторские свидетельства.

Профессиональные интересы – создание архитектуры корпоративных и банковских информационных систем, поиск баланса между общими архитектурными подходами и реализацией специфических требований заказных проектов.

Максим активно участвует в развитии внутренних процессов и совершенствовании практик применения гибких методологий разработки и коллективного проектирования в CUSTIS.

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.