Просмотр исходного текста страницы DDD: модели вместо требований 9 лет спустя (ЛАФ-2023)

{{RightNote|[[:Категория:DDD|Еще про DDD]]}}
 10-11.06.2023 под Костромой [https://lafest.ru '''ЛАФ-2023''']
 [https://conf.uml2.ru/class/ddd-modeli-vmesto-trebovanii.html Доклад на сайте конференции]
 Видео https://vimeo.com/844929617 

Девять лет назад на AnalystDays-2014 я делал доклад «[[DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)|'''DDD - модель вместо требований''']]». С тех пор мое представление о Domain Driven Design развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое. Все это будет в докладе вместе с основами DDD, которые делают его более эффективным способом проектирования приложений, чем классическая работа с требованиями: концепциями единого языка, ограниченных контекстов и единой моделью, прозрачно отражаемой в код. 

По теме недавно была статья [https://habr.com/ru/company/custis/blog/705958/ '''Domain Driven Design: модели вместо требований'''], но она - обзорная, верхнего уровня. В докладе [[Требования или модели - как писать постановки (AnalystDays-2023)]] я тоже, естественно,  затрагивал тему DDD, но там это была 1/6 доклада. И более ранних докладов было много, но в этом - новая полная версия и многое переосмыслено, обсуждение статей и докладов послужило драйвером для этого.

Предыдущие доклады по теме [[Domain-driven design: от справочников и документов до отчетов (WIAD-2020)]] и [[DDD в современной архитектуре: как отражать модель в код (Podlodka Techlead-2021)]].

= Основные тезисы = 

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

# Классическая схема работы с требованиями: описание предметной области и определение места системы, требования к ней как к черному ящику, дизайн системы на основе этих требований. Способы описания предметной области и дизайна системы постепенно развивались, сначала был процедурный подход, потом - объектный, который распространили и на описание предметной области (Object-Oriented Design and Analysis). UML как средство формального построения моделей. 
# Проблемы такого способа работы. Проблемы - с конкретными примерами.
## В динамичных областях, к которым относятся и бизнес-приложения: при изменениях бизнеса в ходе проекта надо заново проходить цепочку. отслеживая согласованность нескольких моделей. При этом конечная цель применения формальных описаний и моделей - гарантия пригодности системы для бизнеса, если она соответствует требованиям - не достигается. 
## Различие языков, применяемых для бизнес-модели и в реализации системы. Связь часто только через словарь предметной области. При дизайне разработчики строят новые абстракции, меняют организацию объектов исходя из удобства реализации в моменте. И дело не только в поддержании соответствия моделей, из-за таких изменений трудоемкость реализации запросов на изменения софта становится непредсказуемой, кажущееся небольшим изменение приводит к масштабному рефакторингу внутри. 
## Для больших областей проблемным является требование целостной и непротиворечивой модели предметной области. Реально для компании оно не выполняется, сотрудники разных отделов вырабатывают собственные представления, заботясь лишь о согласовании в сквозных процессах.
# Решение, которое предлагает DDD.
## Выработать единый язык проекта, на котором описывается как модель предметной области, так и модель системы. Язык должен быть понятен заказчику.
## Выделение ограниченных контекстов в предметной области, согласование между ними различными способами.
## Быстро перейти от требований к модели системы. Описание модели должно быть понятно заказчику, это накладывает ограничения на сложность, но они - разумные. Требования при этом можно описывать в легких форматах, например, user story.
## Модель должна иметь регулярное отражение в код. Простой способ - использование Rich Objects, в современных архитектурах он не слишком применимый, но есть другие варианты. 
## Дизайн системы может менять модель, но тогда должен быть обратный ход к заказчику с объяснением изменений и акцептом на них. Типичная ошибка - когда разработчики предлагают общее решение для нескольких кейсов. основываясь на поверхностной схожести, в то время как бизнес видит реальные различия, в том числе в будущем развитии процессов.
# Пример DDD для enterprise-приложений - на основе моего опыта. 
## Общая схема модели с использованием объектных моделей, применяемые средства моделирования, примеры конкретных решений.
## Именование объектов, использование названий типов, атрибутов и методов из модели в интерфейсе для названий полей, действий, сообщений пользователю, что позволяет однозначно идентифицировать проблему при работе с инцидентами.
## Примеры развития - реализация новых процессов и фич. Здесь фокус на том, чем наличие модели отличается от классической конструкции. когда у нас есть просто структуры данных и макеты интерфейсов.
# Уместность DDD. Принципиальное различие между поддерживающими бизнес-процессы системами и теми, которые являются основой организации бизнес-процессов. В первом случае можно ограничиться легкими решениями, в то время как во втором необходима опора на модели и DDD. Цифровизация приводит к тому, что второй вариант становится все более распространенным.

= Видео =

{{Vimeoembed|844929617|800|450}}

= Презентация =
{{Presentation|DDD-LAF-2023-Tsepkov-CUSTIS.pdf|290px}}

[[Категория:DDD]][[Категория:Доклады]]