Привет! Меня зовут Станислав, я фронтенд-разработчик компании Тинькофф. Занимаюсь разработкой веб-приложений и написал десятки тысяч строк кода, массу велосипедов и костылей, пока не познакомился с разработкой, основанной на модели предметной области, или Domain-Driven Design.
DDD — это система знаний, приемов и методов, предназначенная для создания приложений высокой сложности. DDD обобщает лучшие практики коммерческой разработки программного обеспечения и постоянно совершенствуется, предоставляя разработчику надежную опору для принятия решений. Лучший способ узнать больше — это книга Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software.
Размышляя о своих прошлых и текущих проектах, попробую перечислить их проблемы, которые могут быть неочевидны до определенного момента развития приложения, и то, как с ними можно справиться, используя базовые принципы DDD.
Бизнес-логика повсюду
Может показаться, что алгоритм решения предметной проблемы лучше и быстрее имплементировать прямо в месте применения: это может быть UI-компонент, часть инфраструктуры фреймворка, метод обращения к API другой системы.
Представим, что, разрабатывая интернет-магазин, мы реализуем форму заказа обратного звонка по номеру телефона и форму для регистрации пользователя. При этом необходимо соблюсти бизнес-правило о приеме только отечественных телефонных номеров.
Задачи делаем в разное время, в проекте заняты несколько бэкенд- и фронтенд-разработчиков.
Если бизнес-правило будет решено в компонентах форм и отдельно в каждом методе бэкенда, мы получим четыре дубликата имплементации бизнес-правила о допустимых телефонных номерах.
Такой подход приводит к потере целостного представления о бизнес-логике, модели начинают неконтролируемо дублироваться и противоречить друг другу, при чтении кода становится сложно анализировать реализацию, есть риск не учесть какой-нибудь костыль, припрятанный в самом неожиданном месте.
В DDD внимание уделяется модели предметной области как в разрабатываемом коде, так и в представлении участников команды. Модель формирует реализацию приложения, которая является ее неотъемлемой частью. Модель предметной области должна содержать необходимые знания о предмете, быть чистой и согласованной.
Для разделения различных аспектов приложения с целью их тщательной проработки наиболее широко применяется многослойная архитектура: отдельные функции программы располагаются в логических слоях и каждый элемент любого слоя может зависеть только от элементов нижележащих слоев и от элементов своего слоя. Часто выделяют такой набор слоев:
Элементы пользовательского интерфейса могут зависеть от элементов трех нижних слоев и от прочих элементов UI, а вот программные компоненты инфраструктурного слоя могут зависеть только от других инфраструктурных компонентов. Состав слоев может отличаться, но для DDD критически важно обособление слоя бизнес-логики.
План такой:
Разделить приложение на логические слои.
Спроектировать слои так, чтобы каждый верхний слой мог зависеть только от нижележащих.
Сосредоточьте весь код бизнес-логики в одном слое.
Изолируйте слой бизнес-логики от остальных слоев.
Это позволит свободно разрабатывать чистую модель предметной области — достаточно большую, чтобы имплементировать необходимую для работы приложения бизнес-логику.
Теперь, практикуя DDD и заботясь об изоляции предметной области, разработчики имплементировали метод валидации телефонных номеров в специальном объекте в доменном слое и обращаются к этому методу в случаях использования из операционного слоя.
Теперь, если интернет-магазин расширит страны присутствия и потребуется расширить правило валидации, нужно будет изменить всего один класс.
Нет разделения на контексты
Проектирование универсальных моделей, которые пытаются решать сразу все задачи, для всех пользователей системы, ведет к тому, что слишком сложная модель становится внутренне противоречивой и хрупкой. Это происходит из-за того, что нет ограничивающих контекстов. Например, изменения отдела снабжения могут задеть функциональность промостраницы или личного кабинета пользователя.
Модель, созданная для первого контакта с пользователем «Клиент», кроме телефонного номера, ФИО, адреса и даты создания оказалась очень удобной для агрегации и других данных для работы с этим пользователем. Разработчики снабдили ее списком рекомендаций, историей покупок, управлением бонусами и историей просмотров.
По ходу усложнения модели пользователя требовалась не только все большая производительность серверов, но и масса труда разработчиков для разрешения конфликтов слияния, борьбы с циклическими зависимостями и чтения огромного количества кода, относящегося почти ко всем сферам деятельности предприятия.
Ограниченный контекст — принцип DDD, согласно которому следует логически разделять приложение на контексты, каждый из которых должен решать задачи соответствующего поддомена предметной области.
Предметно-ориентированное проектирование предлагает ряд методов для разделения сложной предметной области на поддомены.
Разделение может проходить по границам деятельности различных ролей пользователей. Также полезным ориентиром будут отдельные бизнес-процессы, для которых разрабатывается ПО или организационная структура предприятия. Наглядный способ выявления разных контекстов — проверка изменения определения одного и того же слова в разных контекстах. Например, договор в контексте торгового отдела имеет совершенно иное определение, чем в контексте отдела кадров.
Выбирайте способ разделения или комбинируйте их с целью получения внутренне связанных контекстов предметной области с малой их взаимной зависимостью между собой. Проектируйте модели каждого из контекстов отдельно: это поможет избежать появления чрезмерно усложненных моделей и лишних связей между контекстами.
Например, после рефакторинга приложение разделили на несколько контекстов: онбординг, магазин, лояльность и доставка. Основной сущностью стал клиент онбординга, в остальных контекстах были созданы модели клиент, содержащие только необходимое им, и дополнительно — идентификатор для связывания с основной сущностью.
Не поддерживается единый язык
В работе случаются проекты с многозначными терминами, жаргоном, неологизмами и массой синонимов при описании модели. Это не только усложняет онбординг новых разработчиков, но и крадет время членов команды на уточнение верного смысла. Приходится постоянно конкретизировать значения, выяснять и запоминать отношения между синонимами.
Например, бизнес-аналитик обсуждает реализацию задачи с новым разработчиком:
— А здесь мы выводим список торговых точек.
— Но у нас нет таких данных.
— Посмотри Shops.
— Нет.
— Markets?
— Нет, вот только какие-то Opportunity Points.
— Да, это то, что нужно!
— ?!
В DDD единый язык — основа для построения моделей в ограниченном контексте, средство коммуникации и трансфера знаний. Он может состоять из наименований классов и операций, включать в себя терминологию для обсуждения правил, которые должны быть явно реализованы в модели. И, конечно, этот язык дополняется наименованиями паттернов, применяемых командой в этой доменной модели.
Единый язык требует осознанного поддержания участниками разработки, актуализации и рефакторинга.
Используйте модель в качестве основы языка. Помогайте другим членам команды использовать этот язык в коммуникациях и коде. Когда находятся лучшие слова и выражения для описания модели, проводите рефакторинг кода, переименуйте классы и методы для соответствия. Устраняйте неоднозначность терминов в обсуждениях. Помните, что изменение в едином языке — это и изменение в модели.
Похоже, что герои примера уже нашли способ повысить эффективность своей работы. Будем надеяться, что они найдут единый язык и смогут решить все стоящие перед ними задачи.
Заключение
Для меня DDD определенно работает, и я рекомендую использовать этот подход. Но опыт любого разработчика уникален, и мне хотелось бы знать, есть ли подобные проблемы у ваших проектов? Работает ли DDD в вашем случае? Напишите, пожалуйста, в комментарии.
