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

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

Скачать весь pdf