Практика реконструкции гостиничных котировок на основе концепции DDD

В августе 2019 года он присоединился к команде внутреннего центра расценок отелей Qunar.com, в основном отвечая за разработку системы, связанной с расценками, и оптимизацию архитектуры. Он очень заинтересован в высокой степени параллелизма и высокой доступности и участвовал в создании нескольких активностей в разных местах. Как и в случае с изучением алгоритмов, соревнования по программированию ACM/ICPC дважды попадали в азиатскую квалификацию. Выиграл первый приз в первом соревновании хакатона Qunar.

1. Введение

Domain-Driven Design, или сокращенно DDD, переводится как Domain-Driven Design. Эта концепция представляет собой метод проектирования системной архитектуры, предложенный с технической точки зрения. Большая часть информации, которую можно найти в Интернете, в основном объяснена с технической точки зрения, и перечисленные случаи также представлены в виде кода, который трудно понять нетехническому персоналу, но для технического персонала различный технический персонал у них очень разное понимание.Позже при проектировании системы посадки часто невозможно запустить,а иногда и не ощущаются конкретные преимущества ДДД.Даже после неудачи некоторых попыток могут отрицательно относиться к ДДД.

DDD — это проектная идея для работы с очень сложными областями.Он пытается отделить сложность технической реализации и построить модель предметной области на основе бизнес-концепций, чтобы контролировать сложность бизнеса, чтобы решить проблемы, которые программное обеспечение трудно понять и решить. эволюционировать. Таким образом, DDD должен быть в основном основан на ремоделировании бизнеса, дополненном реконструкцией системы, и устанавливать консенсус и принципы в отношении режима работы бизнеса, системного разделения труда и границ внутри команды, и в то же время учитывать масштабируемость. будущее развитие бизнеса Системный инжиниринг.

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

2. Восстановите фон

Давайте рассмотрим основной процесс расчета котировок, разобравшись до реконструкции:

Из приведенного выше рисунка видно, что бизнес системы котировок является относительно сложным, и можно увидеть явление: пока здесь связан бизнес, связанный с «ценой», разные бизнесы имеют разные значения «цены». Разбейте это с точки зрения бизнеса:

Как видно из этих двух рисунков, система котировок сделала много дел, не связанных с «ценой», и связала множество различных бизнес-команд. С точки зрения их соответствующих команд, их бизнес-потребности связаны с «ценой», поэтому они, естественно, обращаются к группе по расценкам, и каждая команда заботится только о том, достигнуты ли их ключевые показатели эффективности и реализованы ли их потребности. Техническая команда, кажется, не может отказать бизнесу, и каждое требование кажется разумным (по крайней мере, на первый взгляд). В результате система становится мешаниной из таких проблем, как:

Системы связаны друг с другом, и различные сервисы взаимодействуют друг с другом, что затрудняет обслуживание. Например: книга свободных номеров — это ресурс с базовой ценой 0, замененной трафиком. учитывайте объем продаж и доход от бесплатного номера.Предлагается, чтобы он был на 1 юань ниже, чем у агента с самой низкой резервной ценой, а резервная цена других агентов рассчитывается в режиме реального времени, когда пользователь запрашивает.Чтобы реализовать этой логике, необходимо вторгнуться в логику расчета котировки.
Эффективность разработки низкая, легко наступить на яму, а устранить проблему непросто. Никто не закрывает бизнес, и результатом соответствующих требований каждой бизнес-группы является то, что никто не может четко объяснить, как связаны эти связанные логики. В результате скрытые ямы почти не видны на этапе планирования, а обнаруживаются только в процессе разработки.Идеальная ситуация, когда требования меняются и перерабатываются, трагическая ситуация, когда меняется вся схема, и предыдущая разработка совершенно недействительна, и стоимость крайне высока.
Основной бизнес был захвачен маргинальным бизнесом, кунжут был сорван, а арбуз потерян. Базовые вычисления котировок часто перекрываются некоторыми пограничными службами, а общие вычисления корректируются и адаптируются. В результате основные службы и пограничные службы смешиваются и влияют друг на друга. Каждый раз, когда выполняется корректировка, связанные службы должны быть вывезены для обсуждения воздействия и адаптации.
Процесс слишком сложен и затрагивает реальную стратегию ценообразования.

Причины вышеуказанных проблем:

Требования быстро меняются, система включает несколько полей, бизнес-логика сложна, а система и бизнес-поля четко не разделены.
Основной причиной является отсутствие бизнес-структуры и зрелой операционной системы. Система в конечном итоге используется для поддержки бизнеса и решения проблем эффективности. Если поддерживаемый бизнес хаотичен, то система обречена. Из-за отсутствия стабильного процесса работы в бизнесе неясны обязанности в бизнес-разделении труда, что, в свою очередь, приводит к нечеткому разделению труда в системе.

Чтобы эффективно решить вышеуказанные проблемы, мы начали реконструкцию, основанную на идее DDD, Суть в том, что продукты и технологии собираются вместе, обсуждают бизнес-игры и достигают консенсуса, а также используют концепцию «домена» для построения новой модели. для завершения бизнеса Модернизация может не только соответствовать существующему основному бизнесу, но и строить планы на будущее развитие бизнеса. В процессе проведите четкую линию границ бизнеса и позиционирования, а затем работайте вместе как эксперты в предметной области, чтобы защитить домен и сказать «нет» необоснованным требованиям!

3. Стадия стратегического проектирования DDD ****3.1 Мозговой штурм: сортировка и обсуждение, основанные на экспертах в предметной области и дополненные технологиями

На данном этапе основная роль — эксперт предметной области, а роль менеджера по продукту (PM) — основная роль до рефакторинга. Этот этап должен быть выполнен хорошо.Так же как и обычные потребности, все могут кратко обсудить вместе и реализовать план, если он осуществим.Это не нормально, и легко впасть в ДДД ради ДДД, и эффект может быть не очень хорошим . При рефакторинге на основе идеи DDD необходимо обратить внимание на следующее.【Две предпосылки】:

Иметь четкое представление о логике основных бизнес-операций. Продукт должен уметь выводить основной бизнес-процесс и планы на будущее, чтобы обсуждение имело четкое направление, а сформулированная модель могла соответствовать текущим потребностям и будущим корректировкам.
Поймите все тонкости некоторых существующих бизнес-потребностей. Продукт разъясняет некоторые основные бизнес-требования и бизнес-игры, которые ограничены различными факторами, такими как текущая архитектура, поэтому их можно целенаправленно реконструировать и улучшать.

Обратите внимание здесь【Один принцип】:

Принцип атомарности бизнеса, четкие границы бизнеса; избегайте дублирования деловых обязанностей и чрезмерной связи.

Также обратите внимание, что【Один метод】:

Уточните принцип атомарности бизнеса: разделите по сути бизнеса, найдите метод сущности бизнеса - разделите исходя из цели развития бизнеса.

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

Трехстороннее ценовое ограничение: с точки зрения отеля применяется для поддержания ценового диапазона и обеспечения прав и интересов продавцов.
Продвижение бизнеса: EBK (крупномасштабные фиксированные мероприятия, льготные клубы, ежедневные специальные предложения, магазин новых клиентов), мероприятия ES (краткосрочные практические мероприятия, специальные предложения Qixi), в основном для упаковки портретов пользователей для удовлетворения конкретных пользователей или конкретных потребностей. маркетинговая деятельность сцены может получить более низкую резервную цену и получить более высокую прибыль.
Облако преимуществ: цена остается прежней, но будут предоставлены дополнительные преимущества (поздний выезд, бесплатный завтрак и т. д.).
Платите и продавайте: во время расчета нет цены, если это не влияет на расчет, он в основном основан на возврате денег и пытается получить ценовую власть.
...

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

3.2 Построение модели: решение существующих проблем и управление сложными процессами

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

**Абстракт: **Абстрагируйте все бизнес-геймплеи, сначала выполните первичные слияния, затем выполните общие слияния и объедините похожие бизнес-геймплеи вместе, насколько это возможно (здесь можно сравнить с высокой связностью в дизайне архитектуры программного обеспечения). Следующий рисунок представляет собой абстракцию основного игрового процесса продукта и технологии во время обсуждения:

**Стандартизация.** После того, как вы создали абстрагированный процесс, вы можете рассмотреть вопрос о стандартизации всего процесса. При реконструкции котировок после нескольких обсуждений мы, наконец, представили модели и концепции электронной коммерции, такие как SPU-SKU, и извлекли масштабируемую модель котировок. Суть заключается в том, чтобы адаптировать персонализированный бизнес к SKU (фактически складским единицам, которые можно сравнить с общими субдоменами в концепции DDD), стандартизировать операции на основе конкретных SKU, а затем в основном адаптировать SKU к новому бизнес-процессу. Для бизнес-игр, которые еще не поддерживаются, вы можете добавить новые атрибуты в SKU и определить обработку новых полей.Бизнес-геймплей чрезвычайно масштабируем.

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

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

4. Фаза тактического проектирования DDD

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

Мы используем более популярную: многоуровневая архитектура + чистая архитектура, которая разделена на три уровня: пользовательский интерфейс, ядро приложения и инфраструктура в соответствии со структурой, рекомендованной DDD, как показано на следующем рисунке:

В этой многоуровневой архитектуре мы подтвердили обязанности каждого уровня:

Пользовательский интерфейс: уровень адаптации котировок используется для адаптации к настройке запросов котировок из разных источников, в основном отражая возможности расширения котировок.
Ядро приложения: уровень стабильности котировок, механизм расчета котировок, который в основном отражает вычислительную мощность ядра котировок.
Инфраструктура: базовый уровень котировок, который в основном инкапсулирует вызовы внешних зависимостей, включая связанные компоненты и системы.

В этой модели «домен» ядра котировок находится в ядре приложения. Мы дополнительно уточнили его в соответствии с предыдущим дизайном модели предметной области и объединили с фактическим процессом расчета и бизнес-формой:

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

Спецификация кода, рекомендованная DDD, строго не соблюдается: причина в том, что в CQRS отсутствует C(команда), цитата здесь в основном расчетная, а операция обновления отсутствует.
Определите основные домены, предоставьте связанные методы обслуживания и не требуйте сводных корней (несколько очерченных доменов используются последовательно во время фактического расчета модели).
Используйте единый контекст на протяжении всего вычислительного процесса.
Спецификация уровня гарантии: различайте уровень интерфейса, уровень приложения и базовый уровень.
Абстрагируйте основной процесс расчета котировок и повторно используйте вычислительную мощность.

Что касаетсяПрограммируемыйивизуализация, в основном в процессе разработки, мы также помещаем его в стадию исследований и разработок для подробного обсуждения.

5. Этап внедрения системы DDD

На этом этапе основной ролью обычно становится технология, но продукт все еще должен сочетать окончательную модель и технологию, чтобы продолжать детализировать фактический процесс. Вот отдельная цитата для справки.Продукт очень ответственен за документирование всех деталей процесса расчета котировки.Пример этого примера, рисунок чертежа, является ядром процесса разработки.Ссылка также большое удобство для новичков, чтобы узнать позже. Продукт такой серьезный, разработка, естественно, неплохая, а дизайн кода и основные процессы также фиксируются с помощью различных диаграмм, что очень практично. Документация и диаграммы, созданные на этом этапе создания продукта и разработки, представляют особую потенциальную ценность.

Естественно, что при такой крупномасштабной реконструкции в процессе легко могут возникнуть некоторые проблемы. Вот краткое изложение нескольких основных проблем и ответов:

Адаптация новых требований: для разработчиков адаптация новых требований в процессе может быть неудобной, но с другой точки зрения, эти требования можно просто использовать для предварительной проверки адаптируемости модели, чтобы соответствующий персонал мог видеть будущее после завершения на этом этапе Вместо этого вам не нужно беспокоиться об эффекте после выхода в онлайн.
Быстрая доставка: чем дольше задержка, тем проще вставить больше требований и увеличить рабочее время, поэтому, когда это необходимо, вам приходится работать сверхурочно, чтобы наверстать упущенное, и вы не можете делать это медленно.
Дополнительные требования: До рефакторинга все наши кейсы автоматизации были на уровне интерфейса, что было очень сложно проверить.После стандартизации процесса новой модели кейсы автоматизации можно настроить на кейсы на уровне модулей, случаи автоматизации более целенаправленны, более эффективны. Поэтому мы провели капитальный рефакторинг автоматизированного кейса.Несмотря на то, что было вложено много времени, это хорошо для общей архитектуры, чтобы завершить единовременное вложение, и оно того стоит. После того, как кейс автоматизации был преобразован с уровня интерфейса на уровень модуля, общий объем кейса также сократился примерно до 25% от предыдущего уровня, и соответственно сократилось время выполнения кейса автоматизации.
Запланированные вложения рабочей силы отнимаются другими высококачественными потребностями: такого рода аварии не всегда могут возникнуть, но если они встречаются, с ними все равно необходимо активно бороться. и в то же время Ну, мы согласовали ритм разработки и тестирования, заранее дали тесту войти в разработанный модуль, и скорректировали некоторые функции, которые можно установить обратно (например, адаптацию инструмента), чтобы они были параллельны тесту после теста . Благодаря различной координации мы очень хорошо решили эту проблему.

Далее поговорим овизуализацияРешите болевые точки ежедневного устранения неполадок. Мы также полностью переписали инструмент устранения неполадок.С помощью новой модели процесс расчета котировок стандартизирован, и только для запросов инструментов все основные данные, участвующие в процессе расчета котировок, выводятся в общий вывод контекстной отладки. информация, а затем визуализируется модулем. Таким образом, через запрос интерфейса инструмента можно восстановить каждый процесс расчета котировки, и можно быстро получить основные данные этого расчета котировки.Такой простой инструмент чрезвычайно практичен, и проблема не отображения дежурной котировки после онлайн-запуска напрямую снижается на 90% выше, потому что каждый может легко выяснить причины через инструменты. Конечно, этот инструмент также очень прост в сопровождении.Инструмент показан на рисунке ниже (часть основной информации скрыта):

В этой части остался одинПрограммируемыйпроблема. В процессе расчета котировок, ограниченном различными каналами и другими факторами, задействованный процесс расчета не совсем одинаков, поэтому существует возможность повторного использования и организации возможностей. Разобравшись с процессами разных каналов, мы обнаружили, что основной процесс и другие процессы сильно различаются, и, как только процессы разных каналов будут определены, они не будут модифицированы, а динамическое расположение может привести к сбоям в работе 0,5 pd может быть завершен, поэтому, хотя мы можем поддерживать оркестровку с помощью кода, мы на самом деле не тратим время на разработку и завершение функции оркестровки, чтобы избежать появления небытия.

После завершения разработки и проверки мы постепенно увеличиваем объем проверки в соответствии с методом серого трафика определенных отелей, определенных небольших городских отелей, популярных городских отелей и полноценных городских отелей и завершаем полный выпуск в течение 3 дней до и после.Весь процесс стабилен и не появляется.Очевидная проблема.

6. Пост-оценка и подведение итогов

Эта реконструкция длилась 3 месяца, а от разработки до полноценного запуска прошло 1,5 месяца, что на день раньше, чем ожидалось.Не будем здесь описывать собственно внутренние эффекты, а подведем итоги по ощущениям всех сторон:

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

Здесь также резюмируем важную роль DDD в этом процессе:

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

DDD привносит новые идеи в рефакторинг основной системы, я надеюсь, что больше команд смогут использовать его и принесут пользу ^_^