Короткая ссылка: DDD-LAF2023

10-11.06.2023 под Костромой ЛАФ-2023
Доклад на сайте конференции

Девять лет назад на 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 как средство формального построения моделей.
Проблемы такого способа работы. Проблемы - с конкретными примерами.
1. В динамичных областях, к которым относятся и бизнес-приложения: при изменениях бизнеса в ходе проекта надо заново проходить цепочку. отслеживая согласованность нескольких моделей. При этом конечная цель применения формальных описаний и моделей - гарантия пригодности системы для бизнеса, если она соответствует требованиям - не достигается.
2. Различие языков, применяемых для бизнес-модели и в реализации системы. Связь часто только через словарь предметной области. При дизайне разработчики строят новые абстракции, меняют организацию объектов исходя из удобства реализации в моменте. И дело не только в поддержании соответствия моделей, из-за таких изменений трудоемкость реализации запросов на изменения софта становится непредсказуемой, кажущееся небольшим изменение приводит к масштабному рефакторингу внутри.
3. Для больших областей проблемным является требование целостной и непротиворечивой модели предметной области. Реально для компании оно не выполняется, сотрудники разных отделов вырабатывают собственные представления, заботясь лишь о согласовании в сквозных процессах.
Решение, которое предлагает DDD.
1. Выработать единый язык проекта, на котором описывается как модель предметной области, так и модель системы. Язык должен быть понятен заказчику.
2. Выделение ограниченных контекстов в предметной области, согласование между ними различными способами.
3. Быстро перейти от требований к модели системы. Описание модели должно быть понятно заказчику, это накладывает ограничения на сложность, но они - разумные. Требования при этом можно описывать в легких форматах, например, user story.
4. Модель должна иметь регулярное отражение в код. Простой способ - использование Rich Objects, в современных архитектурах он не слишком применимый, но есть другие варианты.
5. Дизайн системы может менять модель, но тогда должен быть обратный ход к заказчику с объяснением изменений и акцептом на них. Типичная ошибка - когда разработчики предлагают общее решение для нескольких кейсов. основываясь на поверхностной схожести, в то время как бизнес видит реальные различия, в том числе в будущем развитии процессов.
Пример DDD для enterprise-приложений - на основе моего опыта.
1. Общая схема модели с использованием объектных моделей, применяемые средства моделирования, примеры конкретных решений.
2. Именование объектов, использование названий типов, атрибутов и методов из модели в интерфейсе для названий полей, действий, сообщений пользователю, что позволяет однозначно идентифицировать проблему при работе с инцидентами.
3. Примеры развития - реализация новых процессов и фич. Здесь фокус на том, чем наличие модели отличается от классической конструкции. когда у нас есть просто структуры данных и макеты интерфейсов.
Уместность DDD. Принципиальное различие между поддерживающими бизнес-процессы системами и теми, которые являются основой организации бизнес-процессов. В первом случае можно ограничиться легкими решениями, в то время как во втором необходима опора на модели и DDD. Цифровизация приводит к тому, что второй вариант становится все более распространенным.