8006
правок
Изменения
м
→Основные тезисы
Предыдущие доклады по теме [[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. Цифровизация приводит к тому, что второй вариант становится все более распространенным.
