Найкраща практика або шаблони проектування для пошуку даних для звітів та інформаційних панелей у додатку, багатому на домени

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

На мій досвід, є дві сторони програми - сторона "завдання", яка в значній мірі керується доменом і є те, де користувачі сильно взаємодіють з доменною моделлю ("двигуном" програми) та стороною звітування, де користувачі отримати дані на основі того, що відбувається на стороні завдання.

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

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

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

Наприклад, скажімо, що для показу списку активних проектів потрібен звіт / інформаційна панель (уявіть 10000 проектів). Кожен проект потребує набору показань, показаних разом із ним, наприклад:

1. загальний бюджет
2. зусилля на сьогоднішній день
3. швидкість опіку
4. дата вичерпання бюджету при поточній швидкості спалювання
5. тощо.

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

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

У цих випадках здається, що SQL добре розбиває дані, а чому б не використовувати їх? Але тоді у вас є ділова логіка поза вашою доменною моделлю. Будь-яку зміну бізнес-логіки доведеться змінити у вашій моделі домену та ваших схемах агрегації звітів.

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

Я додав тег MVC, тому що MVC - це дизайнерський смак дю пурі, і я використовую його в моєму теперішньому дизайні, але не можу зрозуміти, як дані звітів вписуються в цей тип додатків.

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

РЕДАКТУЙТЕ ТА ІНШИЙ ПРИКЛАД

Ще один ідеальний приклад, який я натрапив сьогодні. Клієнт хоче звіту для Команди з продажу клієнтів. Вони хочуть того, що здається простим показником:

Для кожного продавця, який їх річний обсяг продажів на сьогоднішній день?

Але це складно. Кожен продавець брав участь у кількох можливостях продажу. Деякі вони виграли, деякі - ні. У кожній можливості продажу є кілька людей з продажу, котрим кожному виділяється відсоток кредиту на продаж відповідно до їх ролі та участі. Отже, тепер уявіть, що ви перейдете через домен для цього ... кількість регідратації об'єкта, яку вам доведеться зробити, щоб витягнути ці дані з бази даних для кожного продавця:

Отримайте всі SalesPeople->
Для кожного отримайте їх SalesOpportunities->
Для кожного отримайте свій відсоток від продажу та обчисліть їхню суму продажу,
а потім складіть всю свою SalesOpportunityсуму продажів.

І це ОДНА метрика. Або ви можете написати SQL-запит, який може зробити це швидко та ефективно та налаштувати його на швидкий.

EDIT 2 - Шаблон CQRS

Я читав про шаблон CQRS і, хоча інтригує, навіть Мартін Фаулер каже, що це не перевірено. Отже, як ця проблема була вирішена в минулому. З цим мали зіткнутися всі в той чи інший момент. Що є усталеним або добре зношеним підходом із результатами успіху?

Редагування 3 - Системи / Інструменти звітності

Інша річ, яку слід враховувати в цьому контексті, - це інструменти звітності. Служби звітування / Crystal Reports, служби аналізу та Cognoscenti тощо, всі очікують на отримання даних із SQL / бази даних. Сумніваюся, ваші дані надійдуть через ваш бізнес пізніше. І все ж вони та інші подібні до них є життєво важливою частиною звітності у багатьох великих системах. Яким чином дані для них правильно обробляються, коли є навіть бізнес-логіка у джерелі даних для цих систем, а також, можливо, у самих звітах?

Це дуже глібова відповідь, але потрапляючи прямо до суті справи:

З точки зору DDD, можливо, думати про звітність як обмежений контекст? Тому, а не думати з точки зору "доменної" моделі домену, ви повинні бути готові думати, що добре мати більше однієї моделі. Так так, це добре, якщо домен, що звітує, має в ньому ділову логіку звітування, як і нормально для операційного домену.

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

Оскільки я бачу, що ви додали щедрості до питання, я прочитав це запитання ще раз і помітив, що ви просите конкретний ресурс для цього, тому я подумав почати з того, щоб запропонувати переглянути інші питання щодо переповнення стека з цього питання, і я знайшов це https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

Загальна суть цього полягає в тому, щоб використовувати CQRS як зразок для вашої системи, що відповідає DDD, і покладатися на обов'язки щодо запиту як спосіб зробити звітність, але я не впевнений, що це корисна відповідь у ваш випадок.

Я також знайшов це http://www.martinfowler.com/bliki/ReportingDatabase.html , з яким я посилався тут: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

Ось цікава стаття від ACM з цього питання: http://dl.acm.org/citation.cfm?id=2064685, але вона знаходиться за платною стіною, тому я не можу її прочитати (не член ОСБ :().

Тут також є відповідь на подібне запитання: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

і це: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

Сподіваюся, це допомагає!

Моє розуміння з вашого запитання таке: Заява на щоденне завдання є

Перегляд >> Контролер >> Модель (BL) >> База даних (Дані)

Заява з метою звітування

Перегляд >> Контролер >> Модель >> База даних (Дані + BL)

Таким чином, зміна в BL для ' application task ' також призведе до зміни в BL звіті . Це ваша справжня проблема? Добре, що все-таки робити зміни двічі, що біль ти мусиш прийняти. Причина в тому, що обидва BL відокремлені відповідними проблемами. Один призначений для отримання даних, а один - для збирання даних. Крім того, ваш оригінальний BL та агрегуючий BL буде записаний різною технологією чи мовою ( C # / java та SQL proc ). Врятуватися від цього немає.

Візьмемо ще один приклад, який не стосується конкретного звітування. Припустимо, компанія XXX відстежує електронні листи всіх користувачів для тлумачення та продає цю інформацію маркетинговим компаніям. Тепер у нього буде один BL для інтерпретації та один BL для агрегування даних для маркетингових компаній. Занепокоєння є різними для обох БЛ. Завтра, якщо їх BL зміниться таким чином, що пошти, що надходять з Куби, слід ігнорувати, то бізнес-логіка буде змінена в обох сторонах.

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

Як ви реалізуєте цей піддомен, швидше за все, буде баланс між (найбільш) архітектурно правильним способом, який ви можете зробити, і тим, що дозволить ваша інфраструктура. Мені подобається починати з першого боку і рухатися до другого лише за необхідності.

Ви, ймовірно, можете розділити це на дві основні проблеми, які ви вирішуєте:

1. Дані агрегування чи зберігання. Це має обробляти деяке джерело даних та поєднувати інформацію таким чином, щоб вона зберігалася в іншому джерелі даних.

2. Запит на агрегований джерело даних для надання бізнес-розвідки.

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

У вас можуть працювати різні працівники або якісь заплановані роботи, які розбиті на кілька рухомих частин:

• Щось запитати
• Щось агрегувати
• Щось зберігати

Сподіваємось, ви зможете побачити, як там просвічують деякі CQRS.

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

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

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

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

Це питання описує схему проектування для вирішення питань обробки результатів запитів, які повертають велику кількість даних. Зазвичай ці запити здійснюються клієнтським процесом у широкій мережі (або в Інтернеті), з одним або декількома середніми рівнями, до реляційної бази даних, що знаходиться на віддаленому сервері.

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

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

Таким чином, ви поділите свої трансакційні дані за певним часом (щотижня, щомісяця, щокварталу, рік) та переміщуйте старі розділи у свій сховище звітів / історії через ETL. Це може бути або не бути сховищем даних із зірковою схемою та розмірами. Ви б використовували інструменти звітності щодо зберігання даних для того, щоб робити спеціальні запити, ролики та пакетні завдання для створення періодичних звітів.

Я б не рекомендував звітувати перед вашим сховищем транзакційних даних.

Якщо ви віддаєте перевагу натискати на це, ось ще думки:

1. "Найкраще" - це суб'єктивне і те, що працює.
2. Я б купував звітний продукт, а не писав їх сам.
3. Якщо ви використовуєте реляційну базу даних, то SQL - єдина гра в місті.
4. Збережені процедури залежать від того, чи є у вас навички їх написання.

Програмне забезпечення для управління проектами, яке ви використовуєте вдома? Я б купив, перш ніж будувати. Щось на зразок Rally та Microsoft Project.

Спочатку деяка термінологія, яку ви називаєте стороною завдання, називається транзакційною, а стороною звітування - Analytics.

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

Те, що було перевірено на суворому рівні, - це доповнення вашої транзакційної обробки аналітичним процесором. Іноді це називають сховищем даних або кубами даних. Найбільша проблема щодо аналітики полягає в тому, що спроба запускати запити проти транзакційних даних у реальному часі в кращому випадку неефективна, оскільки реально оптимізувати базу даних для читання чи запису можливо лише. Для транзакцій потрібно мати високу швидкість запису, щоб уникнути затримок в обробці / виконанні речей. Для звітування потрібно мати високу швидкість читання, щоб можна було приймати рішення.

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

Відмінна книга для швидкого зберігання даних - це Інструментарій зберігання даних від Ральфа Кімбала. Для більшої руки на підході Завантажте пробну версію SQL Server та підберіть інструментарій Microsoft Data Warehouse, який займає загальне обговорення першої книги, але показує, як застосувати концепції за допомогою SQL Server.

На цих сторінках є кілька пов’язаних книг, де детальніше про ETL, Star Schema Design, BI, інформаційні панелі та інші теми, які допоможуть вам пройти далі.

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

Що щодо звітної сторони? Чи є сховищами даних прийнятними, чи вони поганий дизайн, оскільки вони включають ділову логіку в базу даних та самі дані?

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

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

Для поліпшення продуктивності запитів можна використовувати матеріалізований вигляд. Коли операція здійснена з вашою моделлю (наприклад, Забронюйте 4 години цього часу для проектування x), і вона успішна, вона може перенести подію, яку ви зможете зберігати в базі даних звітів і робити необхідні розрахунки для свого звіту. Тоді буде дуже швидко запитувати на нього.

Зберігайте окремі контексти транзакцій та звітів, була створена реляційна база даних для повідомлення про доменну модель.

EDIT

Корисна публікація в блозі на тему http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

Минуло 4 роки, і я просто знову знайшов це питання, і у мене є те, що, на мене, відповідь.

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

Я вважаю за краще, щоб вони були фізично окремими (крім того, що вони були логічно окремими), але багато разів ви починаєте їх разом (фізично), а потім, коли програма дозріває, ви розділяєте їх.

Так чи інакше, знову ж таки, вони повинні логічно відрізнятися. Добре дублювати бізнес-логіку в системі звітності. Важливим є те, що система звітності отримує ту саму відповідь, що і доменна система, але є ймовірність, що вона потрапить туди різними способами. Наприклад, у вашій доменній системі буде впроваджено багато суворих правил бізнесу, реалізованих у процедурному кодексі (ймовірно). Система звітування могла б реалізувати ті самі правила, коли вона читає дані, але це зробить за допомогою коду на основі SET (наприклад, SQL).

Ось як реально може виглядати еволюція архітектури вашої програми, коли вона розвивається:

Рівень 1 - логічно відокремлені доменні системи та системи звітування, але все ще в одній і тій же кодовій базі даних та базі даних

Рівень 2 - логічно відокремлені доменні системи та системи звітності, але зараз окремі бази даних із синхронізацією.

Рівень 3 - Логічно та фізично розділені доменні системи та системи звітності та окремі бази даних із синхронізацією.

Основна ідея полягає в тому, що звітність та домен мають радикально різні потреби. Різні профілі даних (читання проти запису та оновлення частоти), різні вимоги до продуктивності тощо. Тому їх потрібно по-різному реалізовувати, що вимагає певного дублювання бізнес-логіки.

Ваша справа повинна розробити спосіб оновлювати логіку бізнесу домену та системи звітування.

звіт / інформаційна панель потрібен для відображення списку активних проектів

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

дата вичерпання бюджету при поточній швидкості спалювання

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

Уявляючи розподілене середовище ( приватне або загальнодоступне хмара ), ви отримаєте величезні витрати на шар обчислень, низьке використання бази даних і повний брак кешу.

Чи слід це спочатку запустити через домен? А як щодо продуктивності?

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

Отже, пошук спочатку, перш ніж завершити архітектуру програмного забезпечення, може бути розподіленою кеш-системою .

(запит: агрегація)! = 1: 1

Я вважаю, що (як для першого, так і для другого прикладу), спробуйте зрозуміти, коли правильно нормалізувати дані, маючи на меті зменшити агрегацію за запитами клієнта. Що не може бути 1: 1 (запит: агрегація), якщо однією метою є отримання стійкої системи.

Розподіліть розрахунок на клієнта

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

Він отримав назву MV *, це правда, що це модно сьогодні, окрім цього, однією з його цілей є створення WebApp (додатка для однієї сторінки), яке можна вважати подарунком багатьох складних додатків (і на щастя для рахунків, які ми платимо постачальнику хмарних послуг, вони виконуються у клієнта).

Отже, мій висновок:

1. Розуміння того, скільки операцій дійсно необхідно для здійснення представлення даних;

2. Проаналізуйте, скільки з них можна зробити у фоновому режимі (а потім розподілити через кеш-систему, після їх нормалізації);

3. Розуміння того, скільки операцій може бути виконано в клієнті, отримання конфігурації проектів, запуску його на Views в WebApp і, таким чином, зменшення обчислень, виконаних в бек-енді;

Використовуйте кеш для запитів, використовуйте домен для кешування.

У stackoverflow є функція під назвою "найкращі користувачі". Ви можете знайти рядок на вершині сторінки найкращих користувачів, в якому йдеться: "У ці підсумки ( щодня оновлюється щоденно )" включені лише питання та відповіді, пов’язані із вікі спільноти . Це вказує на кешування даних.

Але чому?

Для випуску може бути. Можливо, вони мають таку ж стурбованість щодо витоку логіки домену ("У цьому випадку до цих підсумків включаються лише питання, що не стосуються вікі-вікі та відповіді").

Як?

Я не знаю, як вони це зробили, тому ось лише здогадка :)

Спочатку нам потрібно знайти цільове питання / відповіді. Завдання для планування може спрацювати, просто витягнути всі потенційні цілі.

По-друге, розглянемо лише одне питання / відповідь. Це не вікі-спільнота? Це протягом 30 днів? Відповісти за допомогою моделей домену досить просто. Підраховуйте голоси та кешуйте їх, якщо задоволені

Тепер у нас є кеш-пам'ять, вони є результатом виведення домену. Запит швидкий і простий, оскільки застосовуються лише прості критерії.

Що робити, якщо результати потребують більш «реального часу»?

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

Чи потрібен CQRS?

Ні з підходом до планування завдання, ні з підходом до подій. Але cqrs має перевагу. Кеш, як правило, орієнтований на високо відображення, якщо спочатку деякі елементи не потрібні, ми можемо взагалі не обчислювати та кешувати їх. CQRS з джерелом пошуку подій допомагає відновити кеш історичних даних шляхом відтворення подій.

Деякі пов'язані питання:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -річ-домен-з-масовими операціями / 19416703 # 19416703

Сподіваюся, це допомагає :)

Відмова:
Я досить недосвідчений у програмах із доменними моделями.
Я розумію всі концепції, і я вже давно думав про те, як застосувати ці поняття до програм, над якими я працюю (які є багатими доменами, але не мають OO, фактичні моделі доменів тощо) .
Це питання є однією з ключових проблем, з якою я також зіткнувся. У мене є ідея, як це вирішити, але, як я щойно сказав ... я просто придумав цю ідею.
Я ще не реалізував його у фактичному проекті, але не бачу причини, чому він не повинен працювати.

Тепер, коли я це зрозумів, ось що я придумав - я використаю ваш перший приклад (проектні метрики) для пояснення:

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

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

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

Отже, коли вам потрібен будь-який вид звіту, усі необхідні дані вже є (попередньо обчислені), і ви можете просто зробити щось подібне:

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

Не має значення, отримуєте ви дані безпосередньо з таблиць, де зберігається модель домену, чи ви якимось чином витягаєте їх до другої бази даних, до сховища даних чи будь-якого іншого:

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

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