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

Доклад был сделан на конференции [http://softwarepeople.ru/2013/ SoftwarePeople-2013]. 
[[Категория:Максим Цепков]] [[Категория:Аналитика (доклады)]] [[Категория:Архитектура (доклады)]] [[Категория:Открытые Семинары]]

= Видео =

{{vimeoembed|64288585|720|405}}

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

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

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

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

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

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

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

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

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

= Презентация =
[[Файл:CUSTIS-Tsepkov-SoftwarePeople-2013.pdf|left|page=-|256px]]
{{----}}
= Об авторе =

[[Файл:MaksTsepkov-1.jpg|thumb|left]]

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

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

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

{{replicate-from-custiswiki-to-lib}}