DDD Максим Юнусов Материалы Подзаголовок • «Большая синяя книга» Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans • сокращенная (и свободная для доступа) версия этой книги, подготовленная порталом InfoQ: Domain Driven Design Quickly. 2 Принципы DDD Определение  Проблемно-ориентированное проектирование (DDD) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов  При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей  В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями бизнеса и кодом 3 Принципы DDD Что не так с моделью ? • Многие программные продукты становятся чрезвычайно сложными, в следствии сложности отображаемой предметной области • Разработчик теряет контроль над сложностью продукта • Создаваемая вами программа — не истинная модель. Это только проявление формы приложения, которой вы хотите достичь • Несмотря на то, что это только имитация идеального решения, можно стараться со временем приблизить код к настоящей форме 4 Принципы DDD Центральная идея Код, «схватывающий» модель, — центральная идея в DDD Создавая программу, которая решает конкретную текущую проблему и ограничена этой проблемой, вы в итоге получаете программу, готовую воспринять новые идеи и озарения 5 Принципы DDD DDD делает концепции явными  Пункт public bool CanBook(Cargo cargo, Voyage voyage) { double maxBooking = voyage.Capacity * 1.1; if (voyage.BookedCargoSize + cargo.Size > maxBooking) return false; ... } public bool CanBook(Cargo cargo, Voyage voyage) { if (!overbookingPolicy.IsAllowed(cargo, voyage)) return false; ... } 6 Принципы DDD Три базовых концепта 1. Модель и дизайн отображаются один в другое – Код всегда актуален и отображает предметную область – Код документирует предметную область 2. Модель является основой языка, используемого всеми членами команды Под членами команды подразумеваются 1. Домен эксперты 2. Разработчики 3. Модель – общее знание – Модель общее поле работы (команда, эксперты (аналитик команды или представитель заказчика)) – Модель постоянно перерабатывается и постоянно в тонусе 7 Принципы DDD Три аспекта DDD 1. Модель 2. Проектирование/Дизайн 3. Архитектура 8 Модель Модель предметной области Модель – это упрощенное (но, не примитивное !) приближение реальности Максимально простое, при условии достаточной близости к действительности Если нет модели понять поведение бывает очень сложно for (int p = 0; p < 12; p++) { CString str_SV, str_SA; sec_V[p] = atoi(str_SV); Алгоритм расчета мощности трансформатора sec_A[p] = atof(str_SA); P2[p] = sec_V[p] * sec_A[p]; P1 += P2[p] / 0.85; } 9 Модель Модели в программировании В настоящее время моделирование в программировании осуществляют через ООП Style OOP Procedural При этом существует три альтернативы: ADM Большенство разработчиков использует ADM подход ! 10 Модель Идеальная модель (Knowledge-rich model) • Модель закладывает не только статику но и поведение • Модель это ментальный образ существующий в представлениях команды и представляемый кодом, диаграммами и т. п. • Модель имеет удобный вид для реализации (участие программистов) и отображает предметную область (доменные специалисты) • Бизнес правила столь же важны для модели сколь и сущности в нее входящие • Сущности и бизнес правила должны трассироваться в код Критерий - код должен быть понятен бизнес экспертам при определенном объяснении разработчиками 11 Модель Представление модели В настоящее время моделирование в программировании осуществляют на UML •Излишне детализированная диаграмма не дает пользы, мешает пониманию модели •Маленькие диаграммы теряют смысл без вербального описания, и требуют объяснения •Детальные диаграммы дублирование кода. Проблема поддержки Диаграммы не могут вытеснить общение ! 12 Модель Использование письменной документации • Зачем в документации информация которую можно найти в коде • Зачем в документации информации которую можно сгенерировать по коду • Документация должна способствовать коммуникации • Каждая команда решает для себя насколько важна документация • Документ должен быть актуален на протяжении проекта 13 Модель Генерация кода по модели • Зло, так как требует детализированных UML диаграмм • Диаграммы должны дополнять код и речь, а не дублировать их 14 Общеупотребительный язык Ubiquitous language Проблема Существует два языка 1. Язык доменных экспертов 2. Язык командной разработки (технический язык) Решение Общеупотребительный (унифицированный) язык (UL) использование языка предметной области в коде сознательно, в качестве постоянного правила очень важно для разработчика 15 Общеупотребительный язык Ubiquitous language • Общеупотребительный язык основа DDD • Он является базисом на котором ваша техническая команда становится частью бизнес процесса и работает в его интересах • Разработчик не гик сидящий в одиночестве и создающий баги • Все что говорят доменные эксперты существует на коротком этапе работы, затем исчезает в диалектах разработчиков На UL должны говорить даже в курилке 16 Ворошение знаний (Crunching Knowledge) Первый этап построения модели выделяем существенное Преобразуем поток знаний в тоненький ручеек Виды деятельности • Мозговой штурм • Экспериментирование • Оттачивание языка (устранение шероховатостей) • Допрос эксперта (вытягивание всего, что может быть полезно) • Объяснение – Зачастую объясняя, понимаешь больше 17 Ворошение знаний Пример: Система продажи билетов на самолет ШАГ 1 Эксперт Есть аэропорты, для каждого известны: название на местном языке, уникальный код (латинскими буквами) и GPS координаты Мы 18 Ворошение знаний Пример: Система продажи билетов на самолет ШАГ 2 Эксперт Аэропорты расположены в городах, для каждого города известно название на местном и английском. Известно растояние от аэропорта до города Мы 19 Ворошение знаний Пример: Система продажи билетов на самолет ШАГ 3 Эксперт Для каждого горада есть информация о стране в которой он находится Мы 20 Ворошение знаний Пример: Система продажи билетов на самолет ШАГ 4 Эксперт Есть информация по рейсам самолетов: • номер рейса (уникален), • аэропорты вылета и прилета, • время вылета (по местному времени), • время прилета (по местному времени) Мы 21 Ворошение знаний Пример: Система продажи билетов на самолет СЛЕДУЮЩИЕ ШАГИ Эксперт 22 Ворошение знаний Пример: Система продажи билетов на самолет СЛЕДУЮЩИЕ ШАГИ Мы 23 Строительные блоки DDD Паттерны • Моделирование структуры • Сущность (Entity) • Объект-значение (Value object) • Упрощение ассоциаций (Cardinality of Associations) • Сервисы (Services) • Агрегаты (Aggregates) • Моделирование жизненного цикла • Фабрики (Factories) • Репозитории (Repositories) • Моделирование ограничений • Спецификация (Specification Pattern) 24 Сущность Entity Сущность идентифицируема Идентификатор сущности неизменен на протяжении всего ее жизненного цикла 25 Объект-значение Value object Не идентифицируем Неизменнен (Immutable) • можно безопасно разделять Сравнение объектов = сравнение данных •позволяет распознавать одинаковые значения, представленные в виде разных объектов Инкапсулирует проверку корректности значения •«Build-in anticorruption layer» Обеспечивает строгую типизацию 26 Упрощение ассоциаций Cardinality of Associations • Снижаем мощность ассоциации усложняя структуру классов • Стремимся устранить все двунаправленные ассоциации 27 Сервисы Services • Сервисы представляют поведение • Обычно поведение приписано к сущности или объекту-значению • Сервис имеет смысл, если поведении трудно соотнести с каким либо другим концептом • Сервис может представлять разделенное поведение 28 Сервисы Services Уровня приложения (Application Servicies) Уровня доменной модели (Domain Servicies) • Инфраструктурные (API к системе сообщений, API для интеграции с внешними системами, …) • Согласованная работа с несколькими объектами («уволить всех сотрудников на заданную букву», …) • Комбинированная алгоритмика (прокладка маршрутов, подбор оптимальных вариантов, …) 29 Агрегаты Aggregates • Для упрощения сложной доменной модели концепты объединяют в кластера по агрегированию • Правила агрегирования • Корень агрегации должен иметь глобальный идентификатор • Внешние сущности ссылаются только на корни • Удаление корня удаляет все объекты в агрегате 30 Фабрики Factories • Сущности порождаются фабриками • Фабрики представлены порождающими паттернами GoF 31 Репозитории Repositories Репозиторий скрывает источник данных (сущностей) за интерфейсом коллекции 32 Репозитории Repositories 33 Спецификация Specification Pattern • Спецификация инкапсулирует бизнес-правила или критерии для выборки данных class GoldCustomerSpecification : ISpecification { public bool IsSatisfiedBy(Customer candidate) { return candidate.TotalPurchases > 1000.0m; } } if (new GoldCustomerSpecification().IsSatisfiedBy(employee)) // apply special discount 34 Спецификация Specification Pattern • Спецификация может использоваться при инстанцированиии объекта var spec = new PizzaSpecification() .BasedOn(new MargaritaPizzaSpecification()) .WithThickCrust() .WithSwirl(Sauces.Bbq) .WithExtraCheese(); var pizza = new PizzaFactory().CreatePizzaFrom(spec); 35 Спецификация Specification Pattern • Спецификация может использоваться при формировании запроса public interface ICustomerRepository { IEnumerable GetCustomersSatisfying( ISpecification spec); } var goldCustomerSpec = new GoldCustomerSpecification(); var customers = this.customerRepository .GetCustomersSatisfying(goldCustomerSpec); 36 Ограниченный контекст Bounded Context Ограниченный контекст – контекст существования модели. Модель не может существовать вне контекста. Другие контексты содержат другие модели и другие диалекты общеупотребительного языка Правил определения контекста не существует, но всем должны быть известны правила ограничивающие контекст При наличии нескольких взаимодействующих контекстов необходимо формировать отображения контекстов (Context Maps) друг в друга 37 Ограниченный контекст Паттерны отображения Разделяемое ядро (Shared Kernel) Две команды используют общую доменную модель для организации взаимодействия Самый сложный с точки зрения поддержки вариант Отношения Пользователь/Заказчик (Customer/Supplier Development Teams) Одна из команд предоставляет сервисы (фиды) другой Тестирование и разработка интерфейсов требует совместной работы 38 Ограниченный контекст Паттерны отображения Конформизм (Conformist) Одна из команд подстраивается под второю, предоставляющую сервисы Качество модели первой команды, при этом, сильно зависит от качества модели второй Антикоррупционный уровень (Anticorruption Layer) Дополнительный слой адаптеров между контекстами, позволяет осуществлять взаимодействие в обоих направлениях и снимает зависимость команд друг от друга 39 Архитектура Традиционная многоуровневая архитектура Business Logic (BLL) Data Access (DAL) Infrastructure Presentation Нижние уровни не взаимодействуют с верхними 40 Архитектура Луковичная архитектура (Onion Architecture) User Interface Application Services Domain Services Domain M Model G Database Services File system etc 41 Архитектура Пример отношений между уровнями 42 Контакты Евгений Кривошеев, ekrivosheyev@scrumtrek.ru Никита Филиппов, nfilippov@scrumtrek.ru Асхат Уразбаев, askhat@scrumtrek.ru «Тяжело в учении – легко в бою» SkillTrek – это дистанционный центр компетенций, где специалисты получают востребованные на рынке знания и навыки в условиях реальных проектов с выбором удобной им загрузки 43 Архитектура Валидация EmployeeController User Interface Application Services IEmailSender Domain Services NewUserForm, NewUserFormValidator Domain M Model Employee, IEmployeeRepository Database Services IOverdraftLimitPolicy G File system IUsernameAvailabilityServic e SmtpEmailSender etc NHibernateEmployeeRepository 44