Теория: Предметная область

Предметно-ориентированное проектирование (Domain-driven design) - это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

Данный термин был впервые введён Э. Эвансом в его книге с таким же названием «Domain-Driven Design».

Представьте себе, что перед вами поставили задачу разработать биллинг (система тарификации, выставление счетов, обработка платежей) для интернет-провайдера. С чего вы начнёте проектирование такой системы? А начать надо с анализа предметной области. Познакомиться с основными сущностями системы и их взаимоотношениями, другими словами, вам будет необходимо разобраться в онтологии предметной области.

И вот тут на сцену выходит DDD. Центральная идея этого подхода заключается в том, что разработчики постоянно активно сотрудничают с экспертами предметной области (со стороны заказчика) и вместе с ними формируют так называемый единый язык. Этот язык будет использоваться для общения между всеми членами команды, а позже отразится в исходном коде разрабатываемой программы.

Ubiquitous Language — это не бизнес-жаргон, навязанный разработчикам, а настоящий язык, созданный целостной командой – экспертами в предметной области, разработчиками, бизнес-аналитиками и всеми, кто вовлечён в создание системы. Роль в команде не столь существенна, поскольку каждый член команды использует для описания проекта единый язык. Процесс создания единого языка более творческий, чем формальный, так как он, как и любой другой естественный язык, постоянно развивается, а те артефакты, которые вначале способствовали разработке полезного единого языка, со временем устаревают. В итоге остаются только самые устойчивые и проверенные элементы.

Наиболее важное для разработчика – это умение слушать экспертов, получать максимальное количество полезных знаний о предметной области. В то же время эксперты также должны прислушиваться к разработчикам и их пожеланиям. Команда учится и растёт вместе, если она действует сплочённо, получая более глубокое понимание бизнеса.

Bounded context

Это второе по значимости свойство DDD после единого языка. Оба эти понятия взаимосвязаны и не могут существовать друг без друга.

Итак, ограниченный контекст – это явная граница, внутри которой существует модель предметной области, которая отображает единый язык в модель программного обеспечения.

В каждом ограниченном контексте существует только один единый язык.

• Ограниченные контексты являются относительно небольшими.
• Ограниченный контекст достаточно велик только для единого языка изолированной предметной области, но не больше.
• Единый значит «вездесущий» или «повсеместный», т. е. язык, на котором говорят члены команды и на котором выражается отдельная модель предметной области, которую разрабатывает команда.
• Язык является единым только в рамках команды, работающей над проектом в едином ограниченном контексте.
• Попытка применить единый язык в рамках всего предприятия или что хуже, среди нескольких предприятий, закончится провалом.

Например, система биллинга крупной телекоммуникационной компании может иметь следующие ключевые элементы (контексты):

• Клиентское обслуживание
• Система безопасности и защиты
• Резервное копирование
• Взаимодействие с платёжными системами
• Ведение отчётности
• Система уведомлений

В этом уроке были представлены самые базовые понятия и идеи предметно-ориентированного проектирования. За более подробным описанием можно обратиться к отличной статье на Хабре, либо к книге Эрика Эванса. Также не могу не порекомендовать моё выступление на одной из региональных конференций, в котором я рассказываю о похожих идеях, помогающих улучшить качество кода, который мы пишем.