предисловие

Как говорится в названии книги Эрика Эванса, отца проектирования, управляемого предметной областью, проектирование, управляемое предметной областью, — это способ справиться с основной сложностью программного обеспечения.

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

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

1. Реконструкция фона дисконт-центра

Мы столкнулись с этой ситуацией в реальном процессе разработки.Поначалу, поскольку бизнес-логика была относительно простой, чтобы быстро реализовать функцию и всесторонне учесть такие факторы, как стоимость и риск, мы создадим большую модель для объединенного бизнеса. Все модули используют одну и ту же модель. Однако с развитием бизнеса логика каждого подполя становится все более и более сложной, и модификация этой большой модели станет катастрофой.Иногда очевидно изменение логики подполя А, но это необъяснимым образом влияет на B или C. Функциональность онлайн для субдоменов.

Примером могут служить центры предложений. Преференциальный центр в основном отвечает за управление преференциальной деятельностью различных направлений деятельности Mafengwo, а также за расчет преференциальных результатов для разных пользователей. Как два разных бизнес-подразделения, «Управление товарами» и «Управление льготами» изначально были разработаны для использования одной товарной модели, которая управляется товарным модулем унифицированным образом.

Рисунок 1: Исходная товарная модель

проблемы

С развитием бизнеса формы скидок постоянно обновляются, бизнес-формы постепенно диверсифицируются, а потребности деловой стороны становятся все более и более персонализированными, что приводит к некоторым специфическим проблемам в более позднем дисконтном центре как с точки зрения функция и система:

1. Функция, это не достаточно гибко

Информация о предпочтениях настраивается в модуле управления товарами как атрибут информации о товарах. Например, чтобы направлять пользователей в использовании Приложения, необходимо установить скидку типа А, что может быть достигнуто путем добавления элемента конфигурации скидки типа А на странице редактирования информации о продукте; если скидка типа А составляет определенный продукт должен вступить в силу в 0:00, студенты-бизнесмены должны подождать до 0:00 перед компьютером, чтобы обновить информацию о продукте для запуска рекламных акций.

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

2. На системном уровне расширять непросто

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

3. Не способствует повторению

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

Реконструируя ожидания дисконтного центра

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

2. Почему стоит выбрать ДДД

Избегайте моделей анемии

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

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

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

В-третьих, процесс посадки

Ключевой момент: абстракция бизнес-логики

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

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

3.1 Тактика проектирования

Шаг 1. Унифицируйте язык и уточните ключевые слова

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

Тип предложения: Указывает предпочтительное правило и соответствующую схему предпочтений. Например, скидка при раннем бронировании — это то, сколько нужно купить раньше (льготные правила) и сколько уменьшить/скидить (льготный план);
Акции: Имейте полный жизненный цикл, необходимо включить время, платформу, персонал, товары и т. Д. (Размеры ограничения), используют информацию о процессе;
Предложить открытие: По указанным продуктам, персоналу и платформам узнать список льготных видов деятельности, которые можно использовать;
Расчет скидки: рассчитать сумму скидки и сведения о скидке, которыми можно воспользоваться при этой покупке, в соответствии с указанным продуктом, персоналом, платформой и количеством покупки;
Сортировка предложений: По порядку рассчитываются разные типы скидок, если есть дисконтированные скидки, то порядок будет другим, и результаты расчета тоже будут другими;
Благоприятное взаимное исключение: Между некоторыми скидками существует взаимоисключающая связь.Например, если вы используете скидку 4% по Золотой карте, вы не можете использовать купоны Mafengwo.

Шаг 2: Абстрактная модель предметной области

В соответствии с принципом единой ответственности одному объекту предметной области соответствует одно понятие предметной области. Объекты домена имеюторганизацияиобъект значенияточки:

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

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

Но есть также некоторые деловые поведения, которые не могут быть отнесены к объекту объекта или стоимости, а также могут быть классифицированы как доменные услуги:

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

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

Шаг 3: Абстрагируйте связь между объектами предметной области

Явно группируйте связанные объекты домена, чтобы выразить концепцию целого (или отдельного объекта домена), то есть «агрегации».

Рекламные акции по отгрузке, такие как полимерный тип, например, предпочтительный ассортимент; Преференциальные правила и льготные программы полимеризации типа доставки; Преференциальные правила, ограничивающие размер полимеризации; Решение для доставки полимеризовано. Транспортные средства:

Рисунок 2: Схематическое представление отношений

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

Шаг 4. Пройдитесь по сцене и настройте модель предметной области.

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

Шаг 5: Упростите дизайн и уменьшите сложность системы

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

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

3.2 Стратегический дизайн

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

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

Отличительные сцены внутри дисконт-центра

Дисконтный центр включает в себя два разных подбизнес-подразделения: управление льготными действиями для пользователей на конце B и расчет скидок для пользователей на конце C:

Рисунок 3: Дискриминация сцен внутри дисконт-центра

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

Интеграция Центра предложений с внешними системами

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

Методы разработки стратегии, используемые вызывающими и вызываемыми абонентами, обычно включают следующее:

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

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

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

Рисунок 4: Бизнес-архитектура дисконтного центра

3.3 Реализация архитектуры

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

Рис. 5. Иерархическая модель домена центра предложений

слой пользовательского интерфейса: обрабатывать логику взаимодействия с конечным пользователем;
Уровень службы приложений: отвечает за инкапсуляцию и преобразование возвращаемых данных уровня предметной области в уровень пользовательского интерфейса;
Слой домена: на этом уровне находится основная логика дисконтного центра, включая объекты предметной области и службы предметной области.
Уровень хранения: уровень хранения отвечает за размещение объектов домена в памяти на носителе данных, а также отвечает за создание объектов домена для использования уровнем домена после получения исходных данных с носителя данных; этот уровень скрывает нижележащее хранилище детали из доменного слоя. Хотя уровень хранения находится ниже уровня домена, мы используем внедрение зависимостей в процессе реализации, чтобы внедрить конкретную реализацию уровня хранения в уровень домена.

4. Проблемы и ближайшие планы

1. Скидка ценового уровня

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

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

2. Проблемы с производительностью

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

V. Резюме

В данной статье представлен некоторый практический опыт реконструкции дисконтного центра электронной коммерции сотовой связи Ma на базе DDD. Идея DDD также помогает нам более разумно проектировать архитектуру в процессе бизнес-итерации.

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

автор этой статьи: Сюй Синван, технический эксперт отдела исследований и разработок платформы сотовой электронной коммерции Ma.

(Исходное содержание Ma Honeycomb Technology, пожалуйста, укажите источник и сохраните изображение QR-кода в конце статьи при перепечатке, спасибо за сотрудничество.)