DDD: модели вместо требований 9 лет спустя (ЛАФ-2023) — различия между версиями
м (→Основные тезисы) |
м |
||
(не показана одна промежуточная версия этого же участника) | |||
Строка 1: | Строка 1: | ||
+ | {{RightNote|[[:Категория:DDD|Еще про DDD]]}} | ||
10-11.06.2023 под Костромой [https://lafest.ru '''ЛАФ-2023'''] | 10-11.06.2023 под Костромой [https://lafest.ru '''ЛАФ-2023'''] | ||
− | [https://conf.uml2.ru/class/ddd-modeli-vmesto-trebovanii.html Доклад на сайте конференции] | + | [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, которые делают его более эффективным способом проектирования приложений, чем классическая работа с требованиями: концепциями единого языка, ограниченных контекстов и единой моделью, прозрачно отражаемой в код. | Девять лет назад на AnalystDays-2014 я делал доклад «[[DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)|'''DDD - модель вместо требований''']]». С тех пор мое представление о Domain Driven Design развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое. Все это будет в докладе вместе с основами DDD, которые делают его более эффективным способом проектирования приложений, чем классическая работа с требованиями: концепциями единого языка, ограниченных контекстов и единой моделью, прозрачно отражаемой в код. | ||
Строка 6: | Строка 8: | ||
По теме недавно была статья [https://habr.com/ru/company/custis/blog/705958/ '''Domain Driven Design: модели вместо требований'''], но она - обзорная, верхнего уровня. В докладе [[Требования или модели - как писать постановки (AnalystDays-2023)]] я тоже, естественно, затрагивал тему DDD, но там это была 1/6 доклада. И более ранних докладов было много, но в этом - новая полная версия и многое переосмыслено, обсуждение статей и докладов послужило драйвером для этого. | По теме недавно была статья [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)]]. | |
= Основные тезисы = | = Основные тезисы = | ||
Строка 28: | Строка 30: | ||
## Примеры развития - реализация новых процессов и фич. Здесь фокус на том, чем наличие модели отличается от классической конструкции. когда у нас есть просто структуры данных и макеты интерфейсов. | ## Примеры развития - реализация новых процессов и фич. Здесь фокус на том, чем наличие модели отличается от классической конструкции. когда у нас есть просто структуры данных и макеты интерфейсов. | ||
# Уместность DDD. Принципиальное различие между поддерживающими бизнес-процессы системами и теми, которые являются основой организации бизнес-процессов. В первом случае можно ограничиться легкими решениями, в то время как во втором необходима опора на модели и DDD. Цифровизация приводит к тому, что второй вариант становится все более распространенным. | # Уместность DDD. Принципиальное различие между поддерживающими бизнес-процессы системами и теми, которые являются основой организации бизнес-процессов. В первом случае можно ограничиться легкими решениями, в то время как во втором необходима опора на модели и DDD. Цифровизация приводит к тому, что второй вариант становится все более распространенным. | ||
+ | |||
+ | = Видео = | ||
+ | |||
+ | {{Vimeoembed|844929617|800|450}} | ||
= Презентация = | = Презентация = |
Текущая версия на 08:54, 17 апреля 2024
10-11.06.2023 под Костромой ЛАФ-2023 Доклад на сайте конференции Видео https://vimeo.com/844929617
Девять лет назад на AnalystDays-2014 я делал доклад «DDD - модель вместо требований». С тех пор мое представление о Domain Driven Design развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое. Все это будет в докладе вместе с основами DDD, которые делают его более эффективным способом проектирования приложений, чем классическая работа с требованиями: концепциями единого языка, ограниченных контекстов и единой моделью, прозрачно отражаемой в код.
По теме недавно была статья 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. Цифровизация приводит к тому, что второй вариант становится все более распространенным.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="https://player.vimeo.com/video/844929617?title=0&portrait=0" width="800" height="450" frameborder="0"></iframe>
Скачать → на странице видео на vimeo, кнопка «Download»