Моделирование данных: структуризация

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

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

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

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

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

Что нужно для хорошей организации:

Сформировать словарь предметной области. Язык предметной области (ubiquitous language), единство терминологии — это кости скелета системы. Расположите термины и их определения там, где они чаще всего используются. Например, в корне Git-репозитория. На ревью жёстко пресекайте любые вольности с терминологией.
Сформулировать соглашение об именовании. Единство стиля, единство подхода задаёт узнаваемую форму и устраняет разночтения и недопонимания. Некоторые IDE позволяют сохранять правила именования в Git-репозиторий, чтобы ими пользовалась вся команда. Дополнительно можно создать модульные тесты на проверку структуры.
Выбрать корректный критерий структуризации. Важность данного требования трудно переоценить, т.к. оно задаёт направление развития, определяет точки роста. Для этого нужны хорошие познания предметной области или, как минимум, проблематики. Согласитесь, что иначе предусмотреть логические слои или очертить ограниченные контексты будет крайне затруднительно. Подобные решения обязательно отражайте в ADR и технической документации.

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

Структура — важная составляющая для функционального роста системы. Именно по этой причине в основе известных подходов моделирования данных лежит определение способа организации данных. Например, Kimball’s modeling, Inmon’s modeling, Data Vault. Между тем, отсутствие единственно верного подхода подчёркивает, что нет универсальной и всеобъемлющей структуры, которая бы подходила всем. Мы, как архитекторы и разработчики, должны выбрать наиболее подходящий вариант, исходя из условий и ограничений.

Завтра я раскрою два других аспекта моделирования данных — переиспользование и производительность. А пока по традиции предлагаю делиться собственным опытом. Насколько у вас сильный болевой порог, когда видите беспорядок или нелогичность в организации?

Понравилась статья?