Таблиці пошуку: чи є вони витоком у доменній моделі?

Ви будуєте систему, яка відстежує компанії. Ці компанії мають контакти. Ці контакти часто є фахівцями, які відповідають лише на певні типи питань, наприклад, виставлення рахунків / платежів, продажів, замовлення та підтримка клієнтів.

Використовуючи дизайн, керований доменом та архітектуру Onion, я моделював це за допомогою таких типів:

• Компанія
  • Має контакти
• Контактна інформація
  • Має типи контактів
• ContactType (enum)
• CompanyRepository (інтерфейс)
• EFCompanyRepository (визначений у зовнішній збірці, використовує EntityFramework, реалізує CompanyRepository)

У нашої команди є думка щодо того, як моделювати базу даних для цього додатка.

Сторона A: Lean DDDers:

• Завдання Домену визначає, які Контактні типи дійсні для Контакту. Додавання таблиці до бази даних для перевірки того, що невідомі типи контактів не збережені, є ознакою непрохідного домену. Це занадто далеко поширює логіку.
• Додавання статичної таблиці до бази даних та відповідного коду є марним. У цьому додатку база даних вирішує одну проблему: зберігайте річ і поверніть її мені. Написання додаткової таблиці та відповідного коду CRUD марно.
• Зміна стратегії стійкості має бути якомога простішою. Більше шансів змінити ці правила бізнесу. Якщо я вирішив, що SQL Server коштує занадто дорожче, мені не хочеться відновлювати всю перевірку, яку я вклав у свою схему.

Сторона B: Традиціоналісти [це, мабуть, не чесна назва. DBCentrists?]:

• Дуже погано мати дані в базі даних, які не мають сенсу без читання коду. Звіти та інші споживачі повинні самі повторювати перелік цінностей.
• Це не так багато коду для завантаження словників типу db на вимогу. Не хвилюйся з цього приводу.
• Якщо джерелом цього є код, а не дані, мені доведеться розгорнути біти замість простого сценарію SQL, коли він змінюється.

Жодна сторона не є правильною чи неправильною, але одна з них, ймовірно, є більш ефективною в довгостроковій перспективі, враховуючи час розробки для початкової розробки, помилки і т. Д. Яка сторона це - чи є кращий компроміс? Що роблять інші команди, що пишуть цей стиль коду?

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

Перше, що зрозуміло: вам потрібна "таблиця пошуку" в моделі. Ваша модель повинна відрізняти різні типи контактів. Це означає, що він зберігає сильно набраний список усіх типів. Потрібно також зіставити з тих сильних типів значення, які серіалізуються до бази даних. Це відображення може знаходитися всередині модуля бази даних. Але список усіх можливих типів все ще буде в моделі. І якщо модель має бути єдиним джерелом істини, то вона не може бути всередині бази даних. Або принаймні, коли список змінюється в моделі, його потрібно змінити в базі даних. І жодного але!

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

Однак, я думаю, що ваші DBCentrists пропускають човен. Моделі доменів говорять про те, що їм потрібно зберігати стійкість. "Звіти та інші споживачі" потребують чогось, на що вони можуть запитати - щось із гідними індексами, як було зазначено в коментарях.

Хто запровадив обмеження, що всі ці різні проблеми потребують підтримки однієї бази даних? Що станеться, якщо ти на це відштовхнешся.

Ключове слово: CQRS.

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

Очевидно, мінус у тому, що він використовує більше дискового простору і не нормалізується.

Плюсом є те, що поле зберігає своє значення у db, ви не закінчуєте магічними числами, що відповідають розміру int значення enum, наприклад, і вам не потрібно керувати версією таблиці пошуку, коли enum змінюється.

Не впевнений, що я би охарактеризував це як різницю DDD проти Trad. Більше, на мій погляд, найкраще базуватись на базі даних централістів проти коду

• Поки ви використовуєте реляційну базу даних, ви повинні тримати таблиці нормалізованими в розумній мірі. Нормалізація допомагає запобігти аномалії вставки та оновлення.
• Відносини однієї програми <-> одна база даних вже не є загальними, багато додатків можуть використовувати декілька баз даних, і одна база даних може використовуватися декількома додатками, тому максимально добре використовувати базу даних, щоб забезпечити референтну цілісність.
• RDBMS - твій друг.
• Ви можете замість цього зберегти сховище ключа-значення і зробити все в коді.