Це друга частина статті про методологію моделювання Cosmos DB. У першій частині я розповів про теоретичну складову, а зараз розгляньмо приклад з e-commerce, який зазвичай добре зрозумілий для більшості.

Концептуальна модель даних

Кейси

Розгляньмо кілька випадків використання, що описують бізнес компанії, котра володіє платформою з електронної комерції.

Клієнт реєструє обліковий запис із різними даними профілю, як-от із адресами й контактною та платіжною інформацією.

Клієнт розміщує замовлення, які складаються з наборів замовлених товарів. Замовлення містить інформацію про оплату та деталі доставки. Замовлення зазвичай прив’язується до одного зі складів, із якого відправляються товари, але його можна розділити на різні пакунки та відправити окремо.

Платформа з електронної комерції продає багато різних товарів. Система постійно контролює їхню наявність на складах, розташованих у різних країнах.

Компанія є багатонаціональною і продає однакові товари в різних країнах у різних розмірах, варіаціях та опціях. Тому, залежно від країни, вони по-різному представлені на веб-сайтах електронної комерції.

Цей список випадків використання спрощений і неповний, але вже демонструє неабиякий рівень складності доменної моделі.

Концептуальна модель даних

Перекладімо це бізнесове визначення на концептуальну модель даних із набором сутностей та взаємозв’язків.

На поданій схемі позначення «гусяча лапка» використовується для відображення множинності відносин. Крім того, розташування об’єктів було побудоване за підходом представлення зв’язків типу «один до багатьох» зліва направо.

/uploads/stories/how-to-apply-cosmos-db-modeling-methodology-using-ddd-aggregates-dot-part-2/db1.jpg?1658259230742

Концептуальна модель даних

Процес роботи додатка

Робочий процес програми комплексний і складається з багатьох різних запитів. Виберімо ті з них, що є показовими та включають об’єкти, описані в концептуальній моделі даних.

Запити можна логічно розділити на такі категорії:

1. Ті, що стосуються Представленого Товару:

Отримати доступ до всіх представлених товарів, відображених за ID країни.
Отримати доступ до всієї інформації про представлені товари, включаючи розміри, варіанти та параметри для певного ID країни та коду SKU.
Створити нові представлені товари, додати інформацію про їхні розміри, варіації, опції.

2. Запити, що стосуються роботи з одиницями товару:

Отримати доступ до інформації про наявність одиниць товарів на певному складі.

3. Запити, що стосуються роботи з обліковим записом:

Створити обліковий запис.
Оновити чи видалити обліковий запис за його ID.
Отримати доступ до банківських рахунків певного облікового запису (за його ID).
Додати банківський рахунок для певного облікового запису (за його ID).
Отримати доступ до/змінити інформацію про адресу в обліковому записі за його ID та типом адреси.
Отримати доступ до контактної інформації в обліковому записі.
Отримати доступ до всіх замовлень з облікового запису.

4. Запити, що стосуються роботи із замовленнями:

Отримати доступ до всіх деталей замовлення за його ID.
Зберегти інформацію про замовлення та одиниці товарів у замовленні.
Отримати доступ до всієї історії статусів замовлення за його ID.
Створити інформацію про пакування та інформацію про доставку для певного замовлення.
Отримати доступ інформації про платежі в замовленні.

DDD дизайн: визначення агрегата

На основі концептуальної діаграми даних, а також робочого процесу програми, визначимо агрегати, ключові та неключові сутності та об’єкти значення.

Різниця між сутностями та об’єктами значення

Такий поділ потрібний у першу чергу через питання бізнес-логіки та природи даних. Як ви пригадуєте із визначень, нам потрібно оцінити важливість ідентичності об’єкта та важливість того, чим він є, порівняно з тим, яким він є.

Рахунок, кредитна картка, банківський Рахунок, контакти, замовлення, оплата, пакування, одиниця товару, склад, країна та спосіб доставки цілком очевидно мають помітні фактори ідентифікації, тому розглядатимемо їх як сутності

Історія статусу замовлення — це реальна подія зміни фактичного статусу, тому її також слід розглядати як сутність.

Представлений товар — це товар, представлений у певній країні у визначених доступних опціях, розмірах і варіантах. Він також має фактор ідентифікації, і його можна розрізнити, тому це — теж сутність.

На відміну від Представленого Товару, такі об’єкти, як Розмір, Варіант і Параметри, в основному важливі через свої атрибути, а не фактори ідентифікації, тому вони є об’єктами значення.

Така сама ситуація і з Основною адресою, Адресою доставки, Типом замовлення, Способом оплати, Типом кредитної картки та Статусом замовлення — це вмістилища з важливою описовою інформацією, які важливі в основному через свої набори атрибутів, а не фактори ідентифікації, тож їх слід розглядати як об’єкти значення.

Одиниця замовлення (Order Item) не може жити без батьківського замовлення, тому не має власного глобального унікального ідентифікатора. Одиниці замовлення — це об’єкти значення, прив’язані до замовлень.

Межі агрегата

Оскільки однією з основних функцій системи електронної комерції є розміщення замовлень і доставка товарів, Об’єкт замовлення є першою кореневою сутністю , яку ми визначаємо.

Облікові записи, Одиниці товару та Склади — це елементи, на які посилаються багато замовлень, і вони використовують багато функціональних можливостей, тому повинні бути кореневими елементами своїх агрегатів.

Представлений товар є окремою частиною функціональності, що відповідає за представлення продуктів в інтерфейсі користувача в різних місцях по всьому світу. Отже, це окремий агрегат.

Країна та Спосіб доставки — це словники, на які посилаються в багатьох місцях, тому вони не можуть бути частиною інших агрегатів і повинні бути кореневими сутностями.

Ми визначили 7 кореневих сутностей, що утворюють скелет для своїх 7 агрегатів. Тепер встановімо межі для цих агрегатів, призначивши їм інші сутності та об’єкти значення.

Такі об’єкти та сутності, як Основна адреса та Адреса доставки облікового запису, Кредитна картка, Банківський рахунок та Контактна інформація, завжди запитуються в контексті конкретного Облікового запису, тому ми переміщуємо ці Об’єкти до агрегата Облікового запису.

Аналогічно, запити про Оплату замовлень, Доставку посилок та Історію статусів замовлення завжди подаються в контексті конкретного замовлення, тому ми переміщуємо ці об’єкти до агрегата Замовлення.

Насамкінець, усі об’єкти значення автоматично призначаються до агрегатів, до яких належать їхні батьківські об’єкти.

Перегляд агрегатів

В результаті вправи з визначення агрегатів ми ідентифікували 7 агрегатів, які можемо назвати так, як звуться їхні ключові об’єкти: Країна, Представлений товар, Обліковий запис, Замовлення, Одиниця товару, Спосіб доставки та Склад.

Межі агрегатів зображені в діаграмі.

/uploads/stories/how-to-apply-cosmos-db-modeling-methodology-using-ddd-aggregates-dot-part-2/db3.jpg?1658259824023

Дизайн агрегатів

Відображення агрегатів у логічній моделі даних

Розгляньмо процес відображення агрегатів у документах та контейнерах Cosmos DB.

MR1

Згідно з правилом відображення MR1, згаданим у попередній частині, ми визначаємо 7 контейнерів, які можемо назвати за кореневими сутностями: Представлений товар, Обліковий запис, Замовлення, Одиниця товару, Країна, Спосіб доставки та Склад.

MR2

MR2 визначає ключ розділення (partition key) для кожного контейнера: ідентифікатори ключових об’єктів, які в нашому випадку дорівнюють ID Продукту, ID Акаунту, ID Замовлення, ID Одиниці, ID Країни, ID Способу доставки та ID Складу відповідно.

MR3

Згідно з MR3, ми відображаємо некореневі сутності в окремих типах документів у тих самих вмістилищах, що і ключові об’єкти, з якими вони зв’язані:

Кредитна картка, Банківський рахунок, Контактна інформація у контейнері Обліковий запис.
Оплата, Пакування, Історія статусів Замовлення у контейнері Замовлення.

MR4

MR4 повідомляє, що робити з об’єктами значення. Тут нам потрібно оцінити темпи зростання та тип відносин із пов’язаними об’єктами.

У нашому прикладі багато об’єктів значення однозначно визначені пов’язаними об’єктами. Це стосується Основної адреси, Адреси доставки, Типу контакту, Типу замовлення, Способу оплати, Типу кредитної картки та Статусу замовлення.

У випадку з Розмірами, Варіантами та Параметрами ми маємо тип зв’язку «один до кількох». Це стосується і відношення Замовлення -> Одиниця Замовлення.

Згідно зі статистикою використання запитів, ми бачимо, що операції оновлення цих об’єктів значення виконуються рідко.

Беручи до уваги ці спостереження, ми можемо моделювати всі об’єкти значення, згадані вище, як об’єкти JSON, вбудовані в батьківські типи документів.

На відміну від попередніх об’єктів значення, об’єкт значення Доступність Товару потенційно може значно зрости в області кожної Одиниці, оскільки кількість Складів, в яких зберігаються Одиниці, може значно зрости. Частота оновлень також може бути дуже високою. Таким чином, відповідно до правила MR4, ми відображаємо Доступність Товару в окремому типі документа в контейнері Одиниця Товару, а не вбудовуємо його в батьківський тип документа Одиниця Товару.

MR5

Згідно з правилом відображення MR5, ми готуємо окремий контейнер-словник для розміщення осиротілих кореневих сутностей Країна, Склад і Метод доставки.

MR6

Усі типи документів, пов’язані з кореневими сутностями з інших контейнерів, посилаються на них, зберігаючи належні фактори ідентифікації батьківських документів.

Розгляньмо результати відображення в діаграмі.

/uploads/stories/how-to-apply-cosmos-db-modeling-methodology-using-ddd-aggregates-dot-part-2/db4.jpg?1658260457223

Логічна модель даних: вмістилища Cosmos, типи документів та вбудовані об’єкти JSON

Фізична оптимізація

Тут можна провести серію фізичних оптимізацій, розгляньмо два з доступних варіантів.

Використовуючи статистику запитів, ми помічаємо, що запит замовлень за ідентифікатором облікового запису дуже популярний і широко використовується. Оскільки контейнер Замовлення є найбільшим, кількість фізичних розділів може зрости щонайменше до десятків. За цих обставин використання індексу на основі ID Акаунта всередині вмістилища Замовлення стає не дуже ефективним. Тому в якості оптимізації для цього сценарію ми поміщаємо копію документів Замовлення у контейнер Обліковий запис, який розділений за ID Облікового запису. Таким чином ми суттєво оптимізували цей запит.

Ще одне наше спостереження — що словник Країна насправді ніколи не змінював тип документа. Отже, ми могли б змінити тип зв’язку — замість того, щоб посилатися на Країну за ID Країни у всіх документах, ми могли б вставити всі необхідні атрибути країни в ці документи. Це зробить запит на читання ефективнішим, видаливши додатковий запит на пошук атрибутів країни за ідентифікатором країни.

Після оптимізації фінальна модель даних виглядатиме так, як зображено на діаграмі:

/uploads/stories/how-to-apply-cosmos-db-modeling-methodology-using-ddd-aggregates-dot-part-2/db5.jpg?1658260794381