SlideShare a Scribd company logo
1 of 39
Download to read offline
DDD: проблемы и решения
при отражении модели
предметной области в код

Максим Цепков,
главный архитектор,
группа компаний CUSTIS
О чем этот доклад?
В применении любой методологии есть этапы
 Смотрим примеры – в них все хорошо
 Применяем, решая возникающие проблемы
 Осмысливаем опыт решения, развивая метод
DDD – не исключение


        В докладе речь пойдет о нашем опыте
        решения проблем, возникающих
        при применении DDD в сложных проектах
                                                2/39
План доклада
1. Идея и внутренние противоречия DDD
2. Проблемы при использовании DDD
3. Технологические рельсы – наш способ решения
4. Адаптация процесса разработки
5. Достигнутые преимущества




                                                 3/39
Идея
и внутренние противоречия DDD




                                4/39
DDD – как оно начиналось
Концептуальная книга Эрика Эванса
  •   на английском – в 2003 г.
  •   на русском – только в 2010 г.




                 Практическая книга Джимми Нильссона
                   • на английском – в 2006 г.
                    •   на русском – в 2007 г. (почти сразу!)

                                                                5/39
Основная идея DDD
РАНЬШЕ

                                  Системный
            Бизнес-
                                   аналитик,   Разработчик
           аналитик
                                  архитектор


           Бизнес-                Модель
Заказчик                                          Код
           модель               приложения



DDD

                                               Разработчик
                 Аналитики и архитектор



Заказчик    Модель на едином языке                Код
Основная идея DDD
РАНЬШЕ

                                  Системный
            Бизнес-
                                   аналитик,       Разработчик
           аналитик
                                  архитектор


           Бизнес-                Модель
Заказчик                                              Код
           модель               приложения



DDD                   Переход к единственной модели
                      на едином языке решил много старых
                      проблем, но породил новые Разработчик
                 Аналитики и архитектор



Заказчик    Модель на едином языке                    Код
Плюсы модели на едином языке
 Единое поле коммуникаций для всех участников
 проекта
 Верификация модели заказчиком и выявление
 наиболее критичных ошибок на этапе постановок
 Простота внесения изменений в требования:
 их не надо протаскивать через несколько моделей
 Гибкость реагирования на ограничения, выявляемые
 при разработке: их можно передать заказчику
 посредством модели и найти решения


                                                   8/39
Подробнее о DDD
О преимуществах единственной модели на едином
языке я рассказывал в докладах на конференциях:
 «DDD: Реализуем проект Вавилонская башня»
 (Software People – 2012)
 «DDD — эффективный способ работы в условиях
 системной сложности» (SECR – 2011)




                                                  9/39
Проблемы при использовании
одной модели
                                       Потому две модели
 Необходимость понимания              и использовали
  модели заказчиком существенно
  ограничивает моделирование
 Технические подробности и сложные формальные методы
  становятся недопустимы
 А без них модель не может служить проектом
  для реализации, нужно дополнительное проектирование

         Единственная модель на едином языке –
         и преимущество DDD, и источник проблем
                                                    10/39
Стандартные пути решения проблем
 ООП – общепринятый и (на простом уровне)
 интуитивно понятный метод
 Модель, сделанная в объектной парадигме, может
 быть представлена заказчику и согласована с ним
 Современные языки поддерживают ООП,
 модель хорошо реализуется с использованием
 шаблонов Domain model и Rich objects

        Этот способ работает, но ограниченно.
        Простого ООП не хватает, а изучать сложный
        заказчики не считают правильным
                                                     11/39
Простое применение DDD
 На основе требований создаем объектную модель
 • структура классов
 • поведение объектов
 • интерфейсы
 Согласуем ее с заказчиком
 Реализуем в коде на основе шаблонов
 Domain model и Rich objects

Что получается?

                                                  12/39
Проблемы при использовании DDD
Практические аспекты




                                 13/39
Большие и сложные объекты
 Бизнес-объект включает все аспекты деятельности
 • Клиент – как субъект делового мира, партнер по сделкам,
   взаимоотношения юридические и управленческие
 • Заказ – полный жизненный цикл от начальных переговоров
   до исполнения, включая юридическое и другое оформление

 Бизнес-объекты тесно связаны между собой

 При отражении в IT-объекты получается очень
  похоже на антипаттерн Big Object
 Сложно понимать, развивать, тестировать
                                                             14/39
Техническое усложнение модели
 Принципы ООП побуждают к декомпозиции,
 что увеличивает число объектов
 Применение шаблонов (стратегии и др.)
 Технические и инфраструктурные атрибуты
 и классы
 Ограничения на объекты со стороны фреймворков
 и обходные пути для их преодоления

 Сложная модель не понимается заказчиком,
  простая – не отражает реализацию
                                              15/39
Ограниченная область DDD-модели
 Подход разрабатывался для слоя бизнес-логики
 Использование объектных языков побуждает
 ограничиться объектными моделями

Хочется
 Использовать модель при проектировании
 интерфейсов
 Расширять способы моделирования


                                                 16/39
Решение –
технологические рельсы


    Отделяем технологические
    аспекты от модели




                               17/39
Что такое технологические рельсы
Технологические рельсы – это способ перевода
модели на едином языке в код
   Платформы, фреймворки и библиотеки
   Способы их организации в единое приложение
   Способы отражения модели приложения в код
   Типовые задачи и design patterns для их реализации
Формулируются на всех уровнях – от архитектуры
до частных задач посылки сообщения

         «Применяем Domain model и Rich Objects» –
         частный случай технологических рельсов
                                                         18/39
По рельсам          Технологические рельсы
                      (шаблоны реализации)

       Модель
   на едином языке       Код




  Термины
единого языка




                                         19/39
А как без рельсов
                  Модель
Бизнес-модель   приложения   Код




                                   20/39
Виды технологических рельсов
 Архитектурные
 Инфраструктурные
 Рельсы предметной области




                               21/39
Архитектурные рельсы
Структура приложения в крупном, например:
 Java с Hibernate и Spring
 Создаем anemic-объекты с разметкой Hibernate
    для каждого бизнес-класса, используем их так же,
    как DTO для интерфейса
   Бизнес-логику каждого класса реализуем в отдельном
    статическом классе
   Документооборот описываем через состояния
    объекта, для реализации используем StateEntity
    с декларативной таблицей состояний…
   …
                                Это способ реализации
                                модели в крупном         22/39
Инфраструктурные рельсы
Способы реализации стандартных задач: печатных
форм, отправки сообщений, интеграции, например:
 Все печатные формы реализуются с помощью
    библиотеки X
   Доступ к библиотеке – через сервис-локатор
   Для бизнес-объекта с печатной формой
    создаем класс PrintForm<TClass>, в котором каждой
    форме соответствует отдельный метод…
   На интерфейсе команды печати появляются
    автоматически, исходя из созданных классов…


                                                        23/39
Рельсы предметной области
Способ реализации конструкций, характерных
для предметной области проекта, например
документа с товарными строками:
 Строки документов хранятся в отдельных таблицах,
    однако в объектной модели доступ к ним –
    исключительно через шапки документов
   Для реализации типовой работы класс документа
    наследуем от WareDoc<TDocHeader, TDocItem>,
    что обеспечивает стандартный функционал…
   Если документ не хранит цены и стоимость, а берет их
    из справочников, реализуем стратегию PriceCalc
   …
                                                           24/39
Как технологические рельсы
решают описанные проблемы?




                             25/39
Рельсы для печатной формы
Задача: Для накладной надо печатать форму
ТОРГ-12
Задача – типовая, решение – единообразное

Требования к решению:
 Отделить печать от бизнес-логики
 Обеспечить независимое тестирование
 Желательно обобщенное решение

         Декомпозиция кода и независимое
         тестирование – признаки хорошего стиля
                                                  26/39
Печать форм: решение 1
Обобщенный сервис ПечатьТорг12
и метод НапечататьТорг12 у класса Накладная

      Накладная
                            ПечатьТорг12

…
ПечатьТорг12поНакладной()
…

 Простое и очевидное решение
 Увеличивается класс Накладная, в нем смешивается
  разнородная бизнес-логика
 Класс Накладная зависит от сервиса печати,
  это сильно затрудняет тестирование
                                                     27/39
Печать форм: решение 2
Обобщенный сервис ПечатьТорг12 и сервис
ПечатьТорг12поНакладной

    Накладная           ПечатьТорг12


         ПечатьТорг12поНакладной


 Логика печати вынесена из бизнес-объектов
 Для тестирования ПечатьТорг12поНакладной
  необходима Накладная со всей инфраструктурой
 Таких классов печати становится довольно много


                                                   28/39
Печать форм: решение 3
Обобщенный сервис ПечатьФормы и сервис
ПечатьТорг12поНакладной

 ДанныеДляПечати       ПечатьФормы


    Накладная           ПечатьТорг12

 Логика печати вынесена из бизнес-объектов
 Печать и бизнес-логика тестируются независимо


       Решение применяем ко всем задачам печати,
       тогда в модели достаточно перечислить формы
                                                     29/39
Расширение модельного поля
 Диаграммы состояний для документооборота
 Использование модели для интерфейсов
 Задачи ведения учета




                                             30/39
Диаграммы состояний
 У класса-документа есть атрибут состояние,
  описывающий текущее место в документообороте
 В модели для документов создаем диаграмму
  состояний, на ней же показываем роли
 В классе для каждого перехода реализуем метод,
  помечая его метаданными
 В начале и в конце метода перехода вызываем
  PreTransit и PostTransit, которые обеспечивают
  логирование и контролируют состояние документа



                                                   31/39
Модель для интерфейсов
 Реализуем конструктор обобщенных интерфейсов
 на основе метаданных бизнес-объектов – таблиц
 с фильтрами для просмотра, диалогов для изменения
 Обеспечиваем точки расширения для реализации
 дополнительной логики

 В постановках на 90% интерфейсов – списки полей
 Реализация требуется только для особых случаев



                                                     32/39
Задачи ведения учета
 Присутствуют в большинстве enterprise-приложений
 Плохо описываются в терминах объектов
Решение
 Специальные диаграммы учета
 Базовое учетное ядро – обобщенный учет
 Шаблон реализации диаграмм учета на учетном ядре
 Учет описывается в адекватных терминах
 Диаграммы обеспечивают эффективное понимание
Подробнее о диаграммах состояний и реализации учета –
в докладе на ADD-2011 «Необъектные модели предметной области»
                                                                33/39
Технологические рельсы
и процесс разработки




                         34/39
Аналитик и архитектор
 В небольших проектах аналитик и архитектор –
 один человек
 В крупных проектах аналитик создает модель,
 а архитектор проектирует техническую реализацию
 В классическом процессе каждый из них работает
 со своей моделью
 В DDD – совместная работа над одной моделью
 Конфликты – ответственность плохо разграничена

                                                   35/39
Разработка «с рельсами»
 Аналитик – создает модель и согласует ее
 Архитектор – отвечает за технологические рельсы,
 которые обеспечивают эффективную реализацию
 Конструкции единого языка – способ синхронизации
 модели с технологическими рельсами

 Разграничение ответственности
 Эффективность проектных решений
  обеспечивается технологическими рельсами
 Параллельная работа над проектом
                                                 36/39
Подводя итоги




                37/39
Что достигнуто?
Технологические рельсы:
 сочетают описание модели в понятных заказчику
  терминах со сложными техническими решениями
 помогают соблюдать ограничения, накладываемые
  фреймворками, платформами и библиотеками
  на организацию программного кода, поддерживают
  их совместную работу и однородность решений в рамках
  проекта
Все это обеспечивает эффективную разработку
и является залогом долгого и успешного развития
ИТ-системы, уже находящейся в эксплуатации
                                                    38/39
Спасибо!
Вопросы?


Максим Цепков
M.Tsepkov@custis.ru

More Related Content

What's hot

Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)
Anton Konstantinov
 
3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений
KewpaN
 
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
Alex V. Petrov
 

What's hot (20)

Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)
 
Itgm #9. dmn. как моделировать принимаемые решения
Itgm #9. dmn. как моделировать принимаемые решенияItgm #9. dmn. как моделировать принимаемые решения
Itgm #9. dmn. как моделировать принимаемые решения
 
DDD Workshop
DDD WorkshopDDD Workshop
DDD Workshop
 
Requirement modelling in software creation process
Requirement modelling in software creation processRequirement modelling in software creation process
Requirement modelling in software creation process
 
Domain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияDomain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требования
 
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
 
Практический анализ по RUP
Практический анализ по RUPПрактический анализ по RUP
Практический анализ по RUP
 
Модель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиМодель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработки
 
Практический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UMLПрактический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UML
 
Необъектные модели предметной области
Необъектные модели предметной областиНеобъектные модели предметной области
Необъектные модели предметной области
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
 
Как выбрать для проекта практики проектирования и работы с требованиями
Как выбрать для проекта практики проектирования и работы с требованиямиКак выбрать для проекта практики проектирования и работы с требованиями
Как выбрать для проекта практики проектирования и работы с требованиями
 
3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений
 
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
 
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
 
Software Engineering Knowledge Matrix
Software Engineering Knowledge MatrixSoftware Engineering Knowledge Matrix
Software Engineering Knowledge Matrix
 
Внедрение Бизнес-Анализа, ИТ Бизнес-Аналитиков и UML
Внедрение Бизнес-Анализа, ИТ Бизнес-Аналитиков и UMLВнедрение Бизнес-Анализа, ИТ Бизнес-Аналитиков и UML
Внедрение Бизнес-Анализа, ИТ Бизнес-Аналитиков и UML
 
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
 
Профессиональный стандарт Специалист по дизайну графических и пользовательски...
Профессиональный стандарт Специалист по дизайну графических и пользовательски...Профессиональный стандарт Специалист по дизайну графических и пользовательски...
Профессиональный стандарт Специалист по дизайну графических и пользовательски...
 

Similar to DDD: проблемы и решения при отражении модели предметной области в код

Внедрение CASE-технологий
Внедрение CASE-технологийВнедрение CASE-технологий
Внедрение CASE-технологий
Отшельник
 
разработка собственной Agile методологии для управления крупными проектами
разработка собственной Agile методологии для управления крупными проектамиразработка собственной Agile методологии для управления крупными проектами
разработка собственной Agile методологии для управления крупными проектами
SQALab
 

Similar to DDD: проблемы и решения при отражении модели предметной области в код (20)

Ddd softwarepeople-2012-tsepkov
Ddd softwarepeople-2012-tsepkovDdd softwarepeople-2012-tsepkov
Ddd softwarepeople-2012-tsepkov
 
Ddd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkovDdd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkov
 
DDD — правильный курс в потоке изменений требований
DDD — правильный курс в потоке изменений требованийDDD — правильный курс в потоке изменений требований
DDD — правильный курс в потоке изменений требований
 
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
Роль бизнес аналитика в разработке собственной Business Rule Engine с нуля ка...
 
Опыт госпроектов и взаимодействия с корпоративными структурами
Опыт госпроектов и взаимодействия с корпоративными структурамиОпыт госпроектов и взаимодействия с корпоративными структурами
Опыт госпроектов и взаимодействия с корпоративными структурами
 
Practice of enterprice development ProfsoUX-2017
Practice of enterprice development  ProfsoUX-2017Practice of enterprice development  ProfsoUX-2017
Practice of enterprice development ProfsoUX-2017
 
Сотрудничество с корпорациями: рецепты из практики
Сотрудничество с корпорациями: рецепты из практикиСотрудничество с корпорациями: рецепты из практики
Сотрудничество с корпорациями: рецепты из практики
 
Внедрение CASE-технологий
Внедрение CASE-технологийВнедрение CASE-технологий
Внедрение CASE-технологий
 
Constructor
ConstructorConstructor
Constructor
 
разработка собственной Agile методологии для управления крупными проектами
разработка собственной Agile методологии для управления крупными проектамиразработка собственной Agile методологии для управления крупными проектами
разработка собственной Agile методологии для управления крупными проектами
 
Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)
 
Roles happy dev-2013-tsepkov
Roles happy dev-2013-tsepkovRoles happy dev-2013-tsepkov
Roles happy dev-2013-tsepkov
 
Рабочая учебная программа
Рабочая учебная программаРабочая учебная программа
Рабочая учебная программа
 
Вебинар "Введение в процесс разработки ПО"
Вебинар "Введение в процесс разработки ПО"Вебинар "Введение в процесс разработки ПО"
Вебинар "Введение в процесс разработки ПО"
 
Применение DDD подхода в Symfony 2 приложении
Применение DDD подхода в Symfony 2 приложенииПрименение DDD подхода в Symfony 2 приложении
Применение DDD подхода в Symfony 2 приложении
 
Why prototypes matter?
Why prototypes matter?Why prototypes matter?
Why prototypes matter?
 
CompanyMedia4You - Нити управления
CompanyMedia4You - Нити управленияCompanyMedia4You - Нити управления
CompanyMedia4You - Нити управления
 
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
 
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ... "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
 

More from CUSTIS

More from CUSTIS (20)

Три истории микросервисов, или MSA для Enterprise
Три истории микросервисов, или MSA для EnterpriseТри истории микросервисов, или MSA для Enterprise
Три истории микросервисов, или MSA для Enterprise
 
Долгоживущие ИТ в динамичном ритейле
Долгоживущие ИТ в динамичном ритейлеДолгоживущие ИТ в динамичном ритейле
Долгоживущие ИТ в динамичном ритейле
 
Будущее уже наступило: от Agile к бирюзовым организациям
Будущее уже наступило: от Agile к бирюзовым организациямБудущее уже наступило: от Agile к бирюзовым организациям
Будущее уже наступило: от Agile к бирюзовым организациям
 
Диаграммы учета как средство для наглядного и целостного отображения правил у...
Диаграммы учета как средство для наглядного и целостного отображения правил у...Диаграммы учета как средство для наглядного и целостного отображения правил у...
Диаграммы учета как средство для наглядного и целостного отображения правил у...
 
Agile — ответ на вызовы третьей промышленной революции
Agile — ответ на вызовы третьей промышленной революцииAgile — ответ на вызовы третьей промышленной революции
Agile — ответ на вызовы третьей промышленной революции
 
Опыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банкеОпыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банке
 
Золотая лихорадка MSA: почему нам не подошли микросервисы?
Золотая лихорадка MSA: почему нам не подошли микросервисы?Золотая лихорадка MSA: почему нам не подошли микросервисы?
Золотая лихорадка MSA: почему нам не подошли микросервисы?
 
Барьеры микросервисной архитектуры
Барьеры микросервисной архитектурыБарьеры микросервисной архитектуры
Барьеры микросервисной архитектуры
 
Три истории микросервисов
Три истории микросервисовТри истории микросервисов
Три истории микросервисов
 
От монолитных моделей предметной области — к модульным
От монолитных моделей предметной области — к модульнымОт монолитных моделей предметной области — к модульным
От монолитных моделей предметной области — к модульным
 
Проблемы управления правами доступа к информационным системам крупной торгово...
Проблемы управления правами доступа к информационным системам крупной торгово...Проблемы управления правами доступа к информационным системам крупной торгово...
Проблемы управления правами доступа к информационным системам крупной торгово...
 
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
Будущее omni-channel маркетинга: инструменты, кейсы и цифрыБудущее omni-channel маркетинга: инструменты, кейсы и цифры
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
 
Agile и управление знаниями в ИТ-проектах
Agile и управление знаниями в ИТ-проектахAgile и управление знаниями в ИТ-проектах
Agile и управление знаниями в ИТ-проектах
 
State of the .Net Performance
State of the .Net PerformanceState of the .Net Performance
State of the .Net Performance
 
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделятьОтветственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
 
Опыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектурыОпыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектуры
 
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватаетГибридный подход к управлению правами доступа: когда стандартного IDM не хватает
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
 
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
 
Process и Case Management в информационной системе: от автоматизации As Is к ...
Process и Case Management в информационной системе: от автоматизации As Is к ...Process и Case Management в информационной системе: от автоматизации As Is к ...
Process и Case Management в информационной системе: от автоматизации As Is к ...
 
RBAC & ABAC: гибридное решение для управления правами доступа
RBAC & ABAC: гибридное решение для управления правами доступаRBAC & ABAC: гибридное решение для управления правами доступа
RBAC & ABAC: гибридное решение для управления правами доступа
 

DDD: проблемы и решения при отражении модели предметной области в код

  • 1. DDD: проблемы и решения при отражении модели предметной области в код Максим Цепков, главный архитектор, группа компаний CUSTIS
  • 2. О чем этот доклад? В применении любой методологии есть этапы  Смотрим примеры – в них все хорошо  Применяем, решая возникающие проблемы  Осмысливаем опыт решения, развивая метод DDD – не исключение В докладе речь пойдет о нашем опыте решения проблем, возникающих при применении DDD в сложных проектах 2/39
  • 3. План доклада 1. Идея и внутренние противоречия DDD 2. Проблемы при использовании DDD 3. Технологические рельсы – наш способ решения 4. Адаптация процесса разработки 5. Достигнутые преимущества 3/39
  • 5. DDD – как оно начиналось Концептуальная книга Эрика Эванса • на английском – в 2003 г. • на русском – только в 2010 г. Практическая книга Джимми Нильссона • на английском – в 2006 г. • на русском – в 2007 г. (почти сразу!) 5/39
  • 6. Основная идея DDD РАНЬШЕ Системный Бизнес- аналитик, Разработчик аналитик архитектор Бизнес- Модель Заказчик Код модель приложения DDD Разработчик Аналитики и архитектор Заказчик Модель на едином языке Код
  • 7. Основная идея DDD РАНЬШЕ Системный Бизнес- аналитик, Разработчик аналитик архитектор Бизнес- Модель Заказчик Код модель приложения DDD Переход к единственной модели на едином языке решил много старых проблем, но породил новые Разработчик Аналитики и архитектор Заказчик Модель на едином языке Код
  • 8. Плюсы модели на едином языке  Единое поле коммуникаций для всех участников проекта  Верификация модели заказчиком и выявление наиболее критичных ошибок на этапе постановок  Простота внесения изменений в требования: их не надо протаскивать через несколько моделей  Гибкость реагирования на ограничения, выявляемые при разработке: их можно передать заказчику посредством модели и найти решения 8/39
  • 9. Подробнее о DDD О преимуществах единственной модели на едином языке я рассказывал в докладах на конференциях:  «DDD: Реализуем проект Вавилонская башня» (Software People – 2012)  «DDD — эффективный способ работы в условиях системной сложности» (SECR – 2011) 9/39
  • 10. Проблемы при использовании одной модели Потому две модели  Необходимость понимания и использовали модели заказчиком существенно ограничивает моделирование  Технические подробности и сложные формальные методы становятся недопустимы  А без них модель не может служить проектом для реализации, нужно дополнительное проектирование Единственная модель на едином языке – и преимущество DDD, и источник проблем 10/39
  • 11. Стандартные пути решения проблем  ООП – общепринятый и (на простом уровне) интуитивно понятный метод  Модель, сделанная в объектной парадигме, может быть представлена заказчику и согласована с ним  Современные языки поддерживают ООП, модель хорошо реализуется с использованием шаблонов Domain model и Rich objects Этот способ работает, но ограниченно. Простого ООП не хватает, а изучать сложный заказчики не считают правильным 11/39
  • 12. Простое применение DDD  На основе требований создаем объектную модель • структура классов • поведение объектов • интерфейсы  Согласуем ее с заказчиком  Реализуем в коде на основе шаблонов Domain model и Rich objects Что получается? 12/39
  • 13. Проблемы при использовании DDD Практические аспекты 13/39
  • 14. Большие и сложные объекты  Бизнес-объект включает все аспекты деятельности • Клиент – как субъект делового мира, партнер по сделкам, взаимоотношения юридические и управленческие • Заказ – полный жизненный цикл от начальных переговоров до исполнения, включая юридическое и другое оформление  Бизнес-объекты тесно связаны между собой  При отражении в IT-объекты получается очень похоже на антипаттерн Big Object  Сложно понимать, развивать, тестировать 14/39
  • 15. Техническое усложнение модели  Принципы ООП побуждают к декомпозиции, что увеличивает число объектов  Применение шаблонов (стратегии и др.)  Технические и инфраструктурные атрибуты и классы  Ограничения на объекты со стороны фреймворков и обходные пути для их преодоления  Сложная модель не понимается заказчиком, простая – не отражает реализацию 15/39
  • 16. Ограниченная область DDD-модели  Подход разрабатывался для слоя бизнес-логики  Использование объектных языков побуждает ограничиться объектными моделями Хочется  Использовать модель при проектировании интерфейсов  Расширять способы моделирования 16/39
  • 17. Решение – технологические рельсы Отделяем технологические аспекты от модели 17/39
  • 18. Что такое технологические рельсы Технологические рельсы – это способ перевода модели на едином языке в код  Платформы, фреймворки и библиотеки  Способы их организации в единое приложение  Способы отражения модели приложения в код  Типовые задачи и design patterns для их реализации Формулируются на всех уровнях – от архитектуры до частных задач посылки сообщения «Применяем Domain model и Rich Objects» – частный случай технологических рельсов 18/39
  • 19. По рельсам  Технологические рельсы (шаблоны реализации) Модель на едином языке Код Термины единого языка 19/39
  • 20. А как без рельсов Модель Бизнес-модель приложения Код 20/39
  • 21. Виды технологических рельсов  Архитектурные  Инфраструктурные  Рельсы предметной области 21/39
  • 22. Архитектурные рельсы Структура приложения в крупном, например:  Java с Hibernate и Spring  Создаем anemic-объекты с разметкой Hibernate для каждого бизнес-класса, используем их так же, как DTO для интерфейса  Бизнес-логику каждого класса реализуем в отдельном статическом классе  Документооборот описываем через состояния объекта, для реализации используем StateEntity с декларативной таблицей состояний…  … Это способ реализации модели в крупном 22/39
  • 23. Инфраструктурные рельсы Способы реализации стандартных задач: печатных форм, отправки сообщений, интеграции, например:  Все печатные формы реализуются с помощью библиотеки X  Доступ к библиотеке – через сервис-локатор  Для бизнес-объекта с печатной формой создаем класс PrintForm<TClass>, в котором каждой форме соответствует отдельный метод…  На интерфейсе команды печати появляются автоматически, исходя из созданных классов… 23/39
  • 24. Рельсы предметной области Способ реализации конструкций, характерных для предметной области проекта, например документа с товарными строками:  Строки документов хранятся в отдельных таблицах, однако в объектной модели доступ к ним – исключительно через шапки документов  Для реализации типовой работы класс документа наследуем от WareDoc<TDocHeader, TDocItem>, что обеспечивает стандартный функционал…  Если документ не хранит цены и стоимость, а берет их из справочников, реализуем стратегию PriceCalc  … 24/39
  • 25. Как технологические рельсы решают описанные проблемы? 25/39
  • 26. Рельсы для печатной формы Задача: Для накладной надо печатать форму ТОРГ-12 Задача – типовая, решение – единообразное Требования к решению:  Отделить печать от бизнес-логики  Обеспечить независимое тестирование  Желательно обобщенное решение Декомпозиция кода и независимое тестирование – признаки хорошего стиля 26/39
  • 27. Печать форм: решение 1 Обобщенный сервис ПечатьТорг12 и метод НапечататьТорг12 у класса Накладная Накладная ПечатьТорг12 … ПечатьТорг12поНакладной() …  Простое и очевидное решение  Увеличивается класс Накладная, в нем смешивается разнородная бизнес-логика  Класс Накладная зависит от сервиса печати, это сильно затрудняет тестирование 27/39
  • 28. Печать форм: решение 2 Обобщенный сервис ПечатьТорг12 и сервис ПечатьТорг12поНакладной Накладная ПечатьТорг12 ПечатьТорг12поНакладной  Логика печати вынесена из бизнес-объектов  Для тестирования ПечатьТорг12поНакладной необходима Накладная со всей инфраструктурой  Таких классов печати становится довольно много 28/39
  • 29. Печать форм: решение 3 Обобщенный сервис ПечатьФормы и сервис ПечатьТорг12поНакладной ДанныеДляПечати ПечатьФормы Накладная ПечатьТорг12  Логика печати вынесена из бизнес-объектов  Печать и бизнес-логика тестируются независимо Решение применяем ко всем задачам печати, тогда в модели достаточно перечислить формы 29/39
  • 30. Расширение модельного поля  Диаграммы состояний для документооборота  Использование модели для интерфейсов  Задачи ведения учета 30/39
  • 31. Диаграммы состояний  У класса-документа есть атрибут состояние, описывающий текущее место в документообороте  В модели для документов создаем диаграмму состояний, на ней же показываем роли  В классе для каждого перехода реализуем метод, помечая его метаданными  В начале и в конце метода перехода вызываем PreTransit и PostTransit, которые обеспечивают логирование и контролируют состояние документа 31/39
  • 32. Модель для интерфейсов  Реализуем конструктор обобщенных интерфейсов на основе метаданных бизнес-объектов – таблиц с фильтрами для просмотра, диалогов для изменения  Обеспечиваем точки расширения для реализации дополнительной логики  В постановках на 90% интерфейсов – списки полей  Реализация требуется только для особых случаев 32/39
  • 33. Задачи ведения учета  Присутствуют в большинстве enterprise-приложений  Плохо описываются в терминах объектов Решение  Специальные диаграммы учета  Базовое учетное ядро – обобщенный учет  Шаблон реализации диаграмм учета на учетном ядре  Учет описывается в адекватных терминах  Диаграммы обеспечивают эффективное понимание Подробнее о диаграммах состояний и реализации учета – в докладе на ADD-2011 «Необъектные модели предметной области» 33/39
  • 35. Аналитик и архитектор  В небольших проектах аналитик и архитектор – один человек  В крупных проектах аналитик создает модель, а архитектор проектирует техническую реализацию  В классическом процессе каждый из них работает со своей моделью  В DDD – совместная работа над одной моделью  Конфликты – ответственность плохо разграничена 35/39
  • 36. Разработка «с рельсами»  Аналитик – создает модель и согласует ее  Архитектор – отвечает за технологические рельсы, которые обеспечивают эффективную реализацию  Конструкции единого языка – способ синхронизации модели с технологическими рельсами  Разграничение ответственности  Эффективность проектных решений обеспечивается технологическими рельсами  Параллельная работа над проектом 36/39
  • 38. Что достигнуто? Технологические рельсы:  сочетают описание модели в понятных заказчику терминах со сложными техническими решениями  помогают соблюдать ограничения, накладываемые фреймворками, платформами и библиотеками на организацию программного кода, поддерживают их совместную работу и однородность решений в рамках проекта Все это обеспечивает эффективную разработку и является залогом долгого и успешного развития ИТ-системы, уже находящейся в эксплуатации 38/39