DDD и аналитика данных

Я сейчас занимаюсь разработкой своего pet-проекта: LMS на базе TG, и подошел к стадии набрасывания первых модели: курсы, лекции и их контент. Всё это вывел для дебага.

Из интересного — на данный момент использую SQLite. Думаю, в итоге на нём и останусь, так как это удобно, особенно учитывая, что пользователи будут создавать ботов. Можно под каждого бота создать свою базу, и если потребуется отдавать данные, достаточно просто передать им файл.

В плане локальной разработки SQLite тоже очень удобен.

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

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

1. Пока не добавлен обработчик события, у вас нет исторических данных, и их зачастую невозможно восстановить.

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

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

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

Что такое аналитика на базе модели предметной области?

Самый простой пример в контексте LMS — это дата, когда студент отправил домашнее задание, и дата, когда его проверили. Оба эти атрибута хранятся в модели данных, что позволяет легко рассчитать скорость проверки ДЗ в BI налету.

Более сложный случай — работа с изменениями.

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

Имутабельнось

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

Миграция данных

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

Качество аналитики зависит от качества исходных данных

Это подводит нас к третьему важному моменту: качество аналитики зависит от качества исходных данных. Подход с SQL-гвардами помогает проверять данные на консистентность, ошибки и пропуски. Это даёт возможность отслеживать качество данных и уверенность в продакшн-системе.

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

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

Так мы избавляемся от необходимости в событийной аналитике!

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

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

И напоследок, существует отличный инструмент — Metabase, аналитическая BI-платформа. 

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

И самое классное:

1. Данные в реальном времени. Аналитики работают с продакшн-базой данных или её репликой и получают актуальные данные.

2. Нет необходимости поддерживать вторую систему аналитики. Это снимает нагрузку с разработчиков.

3. Доступ к историческим данным. У бизнеса всегда есть возможность смотреть исторические данные без задержек на сбор информации.

P.S. Если у вас есть вопросы или свои подходы к аналитике в DDD, буду рад услышать ваши идеи в комментариях!