Лучшие практики или шаблоны проектирования для извлечения данных для отчетов и панелей мониторинга в доменном приложении

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

По моему опыту, есть две стороны приложения - сторона «задачи», которая в значительной степени зависит от домена и где пользователи активно взаимодействуют с моделью домена («движок» приложения) и сторона отчетности, где пользователи получить данные на основе того, что происходит на стороне задачи.

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

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

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

В качестве примера предположим, что для отображения списка активных проектов необходим отчет / панель инструментов (представьте 10 000 проектов). Каждому проекту потребуется набор метрик, показанных вместе с ним, например:

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

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

Должно ли это сначала выполняться через домен? Как насчет производительности? Даже с прямыми SQL-запросами я едва получаю эти данные достаточно быстро, чтобы клиент отображал их в разумные сроки. Я не могу себе представить, чтобы попытаться передать эти данные клиенту достаточно быстро, если я перекомпилирую все эти доменные объекты, и смешиваю и сопоставляю и объединяю их данные на прикладном уровне, или пытаюсь объединить данные в приложении.

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

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

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

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

РЕДАКТИРОВАТЬ И ДРУГОЙ ПРИМЕР

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

Каков годовой объем продаж для каждого продавца?

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

Получить все SalesPeople->
Для каждого получить свои SalesOpportunities->
Для каждого получить свой процент от продажи и рассчитать сумму продаж, а
затем сложить все свои SalesOpportunityсуммы продаж.

И это ОДНА метрика. Или вы можете написать запрос SQL, который может сделать это быстро и эффективно и настроить его на быструю.

РЕДАКТИРОВАТЬ 2 - CQRS Pattern

Я читал о паттерне CQRS и, хотя и интригует, даже Мартин Фаулер говорит, что он не тестировался. Так как же эта проблема была решена в прошлом. С этим должны были сталкиваться все в тот или иной момент. Что такое устоявшийся или изношенный подход с успехом?

Редактировать 3 - Системы отчетности / Инструменты

Еще одна вещь, которую следует рассмотреть в этом контексте, это инструменты отчетности. Службы Reporting Services / Crystal Reports, Analysis Services и Cognoscenti и т. Д. Все ожидают данных из SQL / базы данных. Я сомневаюсь, что ваши данные поступят через ваш бизнес позже для них. И все же они и другие, подобные им, являются важной частью отчетности во многих крупных системах. Как правильно обрабатываются данные для них, если в источнике данных для этих систем, а также, возможно, в самих отчетах есть даже бизнес-логика?

Это очень беспечный ответ, но суть дела в сути:

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

Что касается вопроса, скажем, хранимых процедур 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, но она за платным экраном, поэтому я не могу ее прочитать (не член ACM :().

Также здесь есть ответ на аналогичный вопрос: 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 для « приложения задачи » также приведет к изменению « отчетности » BL. Это ваша настоящая проблема, верно? Хорошо, это нормально, чтобы делать изменения дважды, ту боль, которую вы должны принять в любом случае. Причина в том, что оба BL разделены их соответствующими проблемами. Один предназначен для извлечения данных, а другой - для агрегирования данных. Кроме того, ваш исходный BL и агрегирующий BL будут написаны на другой технологии или языке ( C # / Java и SQL ProC ). От этого нет спасения.

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

Отчетность - это ограниченный контекст или поддомен, чтобы говорить свободно. Это решает бизнес-необходимость сбора / агрегирования данных и их обработки для получения бизнес-аналитики.

То, как вы реализуете этот поддомен, вероятно, будет балансом между (наиболее) архитектурно правильным способом, которым вы можете это сделать, и тем, что позволит ваша инфраструктура. Мне нравится начинать с первой стороны и двигаться ко второй только по мере необходимости.

Вероятно, вы можете разделить это на две основные проблемы, которые вы решаете:

1. Агрегирование или складирование данных. Это должно обработать некоторый источник данных и объединить информацию таким образом, чтобы она сохранялась в другом источнике данных.

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

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

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

• Что-то для запроса
• Нечто для агрегирования
• Что-то хранить

Надеюсь, вы увидите, что некоторые из CQRS просвечивают там.

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

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

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

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

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

Я бы не рекомендовал составлять отчеты по вашему транзакционному хранилищу данных.

Если вы предпочитаете нажимать, вот еще мысли:

1. «Лучшее» субъективно и то, что работает.
2. Я бы купил отчетный продукт, а не написал бы сам.
3. Если вы используете реляционную базу данных, то SQL - единственная игра в городе.
4. Хранимые процедуры зависят от того, есть ли у вас навыки для их написания.

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

Сначала некоторая терминология, которую вы называете стороной задачи, называется Транзакционной, а сторона отчетности - Аналитикой.

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

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

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

Отличная книга, чтобы быстро освоить хранилище данных - это набор инструментов хранилища данных Ральфа Кимбалла. Для более практического подхода. Загрузите пробную версию SQL Server и возьмите набор инструментов Microsoft Data Warehouse, который содержит общее обсуждение первой книги, но показывает, как применять концепции с использованием SQL Server.

На этих страницах есть несколько связанных книг, в которых вы найдете более подробную информацию о ETL, Star Schema Design, BI, Dashboards и других темах, которые помогут вам в этом.

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

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

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

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

А как насчет отчетности? Приемлемы ли хранилища данных или они плохо спроектированы, потому что включают в себя бизнес-логику в базе данных и сами данные?

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

Ваша доменная модель должна обеспечивать соблюдение инвариантов вашего домена, например, член проекта не может бронировать один и тот же проект в одно и то же время или может бронировать только x часов в неделю. Или вы не можете забронировать этот проект, так как он завершен и т. Д. Состояние вашей доменной модели (данные) можно скопировать для отчетности отдельно.

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

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

РЕДАКТИРОВАТЬ

Полезное сообщение в блоге на эту тему 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. Понимание того, сколько операций может быть выполнено на клиенте, получение конфигурации проектов, запуск его в представлениях в WebApp и, следовательно, сокращение вычислений, выполняемых в бэкэнде;

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

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

Но почему?

Возможно, из-за проблем с производительностью. Возможно, они одинаково озабочены утечкой логики домена (в данном случае «только вопросы и ответы не из сообщества»).

Как?

Я действительно не знаю, как они это сделали, так что это только предположение :)

Во-первых, нам нужно найти целевой вопрос / ответы. Задача планирования может сработать, просто выберите все потенциальные цели.

Во-вторых, давайте рассмотрим только один вопрос / ответ. Это не вики-сообщество? Это в течение 30 дней? С моделями доменов ответить довольно просто. Подсчитайте голоса и сохраните их, если они вас устраивают.

Теперь у нас есть кеш, они выводятся из доменных производных. Запрос является быстрым и простым, потому что есть только простые критерии, которые должны быть применены.

Что делать, если результаты должны быть более «в реальном времени»?

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

Нужен ли 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

Надеюсь, это поможет :)

Отказ от ответственности:
я довольно неопытен в приложениях с моделями доменов.
Я понимаю все концепции и уже давно думаю о том, как применить эти концепции к приложениям, над которыми я работаю (которые являются доменными, но не имеют ОО, реальных моделей доменов и т . Д.) .
Этот вопрос является одной из ключевых проблем, с которыми я также столкнулся. У меня есть идея, как это решить, но, как я только что сказал ... это просто идея, которая мне пришла в голову.
Я еще не реализовал его в реальном проекте, но не вижу причины, по которой он не должен работать.

Теперь, когда я ясно дал понять, вот что я придумал - я буду использовать ваш первый пример (метрики проекта), чтобы объяснить:

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

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

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

Поэтому, когда вам нужен какой-либо отчет, все необходимые данные уже есть (предварительно рассчитаны), и вы можете просто сделать что-то вроде этого:

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

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

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

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