Информационная архитектура: сущности (теория)

• Все статьи цикла:
• Информационная архитектура: краткий экскурс
• Информационная архитектура: пример и типизация
• Информационная архитектура: сущности (теория) (вы здесь)
• Информационная архитектура: сущности (практика, vol.1)
• Информационная архитектура: сущности (практика, vol.2)
• Информационная архитектура: модели (coming soon)
• Информационная архитектура: практические советы (coming soon)

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

1. Вокабуляр

Для начала давайте вспомним некоторые определения, которые помогут вам ориентироваться в этой статье:

Информационная сущность — устойчивый тип информации в домене продукта (товар, пользователь, заказ, пост, коллекция, организация и тп), обладающий набором свойств и связей.

Свойство сущности — характеристика, описывающая сущность количественно или качественно (название, цена, цвет, дата создания и тп). Свойства могут быть разных типов, заполняться и проверяться по разным правилам, быть «зависимыми» или нет.

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

Термин таксономии — конкретная единица этой классификации (например, категория «Кроссовки» в таксономии «Обувь»).

Фасет — нормализованный атрибут, используемый для фильтрации и уточнения поиска (бренд, цвет, размер и тп).

2. Что такое «сущность» и чем она не является

Сущность всегда:

• имеет роль в домене (зачем она нужна, какую задачу выполняет);
• несёт набор свойств (атрибутов);
• находится в связях с другими сущностями или таксономиями;
• проходит жизненный цикл (например: создание, модерация, публикация, удаление).

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

• со страницей/экраном (это представление сущности в одном из контекстов);
• с UI‑компонентом (это способ отображения свойства или связи);
• с таблицей БД (это реализация хранения, одна сущность может жить в нескольких таблицах и наоборот);
• с бизнес‑процессом (это поведение вокруг данных: процесс «оформить заказ» использует сущности «корзина», «заказ», «платёж»).

Небольшая оговорка: иногда название сущности совпадает с названием представления, это абсолютно нормально. В контент‑ориентированных продуктах (CMS, документация, лендинги) тип «Страница» может быть полноценной контент‑сущностью с собственными свойствами (название, ярлык, текст, автор и тп) и жизненным циклом. Тезис «страница — не сущность» касается только путаницы между сущностью домена и экраном интерфейса (UI‑представлением).

Сложно? На самом деле нет. Вот вам простой тест. Объект — это сущность, если содержит хотя бы 3 из следующих признаков:

• имеет собственные свойства;
• имеет связи с другими объектами;
• повторяется во множестве экземпляров;
• нужен в отчётности/поиске;
• имеет собственные правила валидации/жизненный цикл.

3. Свойства сущности

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

3.1. Типы свойств

Свойства могут быть нескольких типов:

• Базовые: идентификатор, название, описания и прочие. Это простые поля, которые содержат типовую информацию. Базовые свойства не ссылаются на другие объекты и, как правило, представлены в виде простых типов данных (строка, число, дата и тп).
• Ссылочные: внешние ключи на другие сущности (например, «идентификатор пользователя» в сущности «заказ»), а также термины таксономий (категория, метка, группа). Ссылочные свойства нужны для того, чтобы гарантированно связать сущности между собой и с терминами таксономий.
• Составные: свойства, которые включают в себя сразу несколько значений, объединённых одной логикой. Составные свойства могут быть однородными и неоднородными:
  • однородные списки (например, изображения: {url, alt},...);
  • неоднородные комплекты (например, габариты: {weight, width, height, depth}).
• Вычисляемые: свойства, для фиксации (сохранения, отображения и тп) которых нужно сначала произвести какие-то операции. Например, это могут быть: цена со скидкой, количество на складе, агрегированный рейтинг.
• Технические: SKU/артикул, временные отметки, статусы модерации/публикации, флаги индексации. Технические свойства редко используются в визуальном представлении (например, в карточке товара из десятка технических свойств будет выводиться только артикул).
• Ограничительные: права доступа (ACL), владельцы, видимость. Их очень легко спутать с техническими, так как они тоже используются больше в логике, чем в представлении. Если сомневаетесь, задайте себе вопрос: «это свойство влияет на возможности пользователей?» — если да, то перед вами именно ограничительное свойство.

И снова небольшое уточнение, чтобы избежать путаницы: типы свойств сущностей — не то же самое, что типы данных, которые эти свойства содержат. Например, если у нашей сущности «товар» есть свойство title (название), то тип свойства здесь — базовый, тогда как тип данных — строка. Подробнее о типах данных я писал здесь.

3.2. Пример описания свойств

Минимальный набор информации, которую желательно фиксировать при описании каждого свойства сущности:

1. название — короткое имя свойства, одно-два слова;
2. код — как это свойство будет называться в коде и базе данных;
3. тип данных — строка, число, массив, объект, ссылка и тп;
4. обязательность — обязано ли свойство быть заполненным, если отметка «да», то значение свойства не может быть пустым;
5. пример — короткий пример заполнения свойства (если пример слишком длинный, он может быть обрезан);
6. описание/комментарий — если требуется вносить какую-то дополнительную информацию.

При желании, этот перечень можно дополнить дополнительными параметрами:

1. источник — откуда берётся значение свойства (логика, подсистемы, интеграции и тп);
2. валидации — базовое правило проверки значения свойства;
3. индексация/поиск — участвует ли свойство в поиске и индексации, если да, то как;
4. политика i18n — для локализуемых свойств: какие переводятся, какие нет;
5. политикой заполнения — кто и когда обязан заполнить.

Вот пример того, как могут фиксироваться свойства сущности «товар» (табличка получилась внушительная, скрольте влево):

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

3.3. Примеры по доменам

Из-за того, что все продукты разные, домены в них тоже могут отличаться. В одном e-com сущность «товар» будет обладать одним набором свойств, в другом — совершенно иным. Порой очень хочется просто взять наработки с прошлого места работы и запихнуть их в текущую архитектуру «как есть». Призываю вас этого не делать, а всегда проектировать сущности, исходя из реалий продукта, процессов, потребностей пользователей и бизнес-задач.

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

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

4. Связи между сущностями

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

4.1. Кардинальности

Кардинальность — это характеристика связи между двумя сущностями (таблицами, объектами, классами и т.д.), показывающая, сколько экземпляров одной сущности может быть связано с экземпляром другой. Проще говоря, это способ ответить на вопрос: «Сколько А может быть связано с одним B?» и наоборот.

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

Подробнее про кардинальности я писал в цикле про дизайн данных, здесь пройдёмся коротко:

• Один-ко-одному, 1:1 — связь, когда каждой записи одной сущности соответствует не более одной записи другой (аккаунт ↔ профиль). Используется для разделения личных и технических данных или выделения редко используемых атрибутов.
• Один-ко-многим, 1:N — наиболее частая связь: один объект верхнего уровня связан с множеством подчинённых (категория → товары; организация → проекты). Применяется для иерархий, коллекций и агрегатов.
• Многие-ко-многим, M:N — объект может быть связан с несколькими другими (товар ↔ теги; пост ↔ автор). Реализуется через промежуточные таблицы/сущности, содержащие идентификаторы обеих сторон и метаданные связи.

4.2. Хранение и производительность

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

Это ещё не дизайн баз данных, но первый шаг к нему.

4.2.1. Ключевые, частые связи

Реализуются как явными внешними ключами (Foreign Key, FK — ссылка из одной таблицы БД на запись другой таблицы), так и отдельными таблицами. Индексируются для быстрого поиска и каскадных операций (например, при удалении пользователя каскадом удаляются его профиль, способы оплаты и тп). Ключевые связи хорошо подходят для данных, которые часто запрашиваются и требуют согласованности.

Например, ключевой связью является связь пользователя и его профиля (1:1) или заказа и товара (1:N).

4.2.2. Вариативные, редкие связи

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

Пример вариативной связи: товар и теги (M:N через JSON или связующую таблицу) или пост и связанные материалы (список ссылок в массиве).

4.2.3. Комбинированный подход

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

Пример комбинированного подхода: заказ и пользователь (жёсткий FK) + история изменений в JSON, товар и его характеристики (основные поля + гибкое поле параметров).

4.3. Поисковые сценарии и индексы

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

Поисковые сценарии — это практические случаи, когда пользователь взаимодействует с данными через поиск, фильтрацию и сортировку.

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

Индексировать можно разные типы полей:

4.3.1. Фасетные поля

Категория, бренд, размер, цвет, материал и прочее. Хранятся в нормализованных словарях или связаны с терминами таксономий, индексируются отдельно. Это даёт возможность строить фильтры и считать количество элементов в каждой группе (это ещё называется «фасетные агрегации»). Чтобы ускорить отклик системы, важно хранить предвычисленные частоты — но это уже совсем мрак, оставим его архитекторам БД.

4.3.2. Поисковые поля

Используют полнотекстовые индексы и префиксные деревья для автодополнения и предложений. Помните, как вы вбиваете что-то в строку поиска, а вам показывают подсказки? Вот это оно. Здесь же добавляются морфологический анализ, поддержка синонимов, транслитерации и нечёткий поиск (fuzzy search).

4.3.3. Сортировочные поля

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

4.3.4. Сложно? Подождите, это ещё не всё

Существует тьма технических приёмов, нацеленных на оптимизацию индексирования: применение комбинированных индексов по частым связкам category_id + price, денормализация популярных связей product → category_name, кэширование фасетных частот для снижения нагрузки и прочее. Но это вам так, если захочется погрузиться.

5. Таксономии и «сквозные» свойства

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

5.1. Иерархическая таксономия

Древовидная структура терминов, где каждый элемент подчинён родительскому (например, дерево категорий или разделов). В таких таксономиях «родительство» обычно обеспечивается отдельным свойством, вроде parent_id.

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

Преимущество: высокая предсказуемость навигации и простота в управлении.

Недостаток: ограниченная гибкость и риск «похоронить» информацию слишком глубоко.

5.2. Плоская таксономия

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

Чаще всего плоские таксономии используется в медиа, блогах и SaaS‑платформах для тегирования и сквозных переходов между материалами.

Преимущество: простота расширения и гибкость.

Недостаток: если не контролировать список терминов, со временем возможна потеря структурности и даже полная поломка логики (например, когда у вас есть 2 разных метки «UX» и «ux»).

5.3. Фасетная таксономия

Объединяет независимые классификации, например: категория, бренд, размер, цена, материал. Пользователь может фильтровать данные сразу по нескольким измерениям.

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

Преимущество: высокая управляемость фильтрацией и быстрый поиск.

Недостаток: сложность проектирования и ухудшение управляемости при росте числа комбинаций.

5.4. Сквозные свойства

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

• живут в единых словарях, которые поддерживаются централизованно;
• используются как фасеты и правила мерчендайзинга/рекомендаций;
• имеют политику синонимов, нормализации значений и правила локализации;
• могут быть жёстко типизированы (enum — о них чуть ниже) или гибкими (текстовые значения, появляющиеся из данных);

Однако у сквозных свойств есть и обратная сторона. Давайте разберём на примере свойства товара «материал».

«Материал» — фасет только при наличии нормализованного словаря (ограниченный справочник материалов). Если материал хранится как произвольный текст (например, «металлический с пластиковыми вставками»), он не является фасетом и остаётся обычным полем: участвует в полнотекстовом поиске, но не в фасетной фильтрации.

6. Противоречивые классификации

Иногда классифицировать сущности оказывается сложно. Хороший пример такой противоречивой классификации — вопрос «где разместить арбуз»? Это ягода (что правильнее с точки зрения ботаники), тыквина (что ещё более правильно) или фрукт (ведь именно там его ищут пользователи)?

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

И для этого существует несколько правил:

1. Вводим приоритеты классификаций (биология < повседневные ожидания < бизнес‑цели каталога). Эти приоритеты задают уровень, на котором принимается решение — например, витрина каталога ориентируется на пользовательскую логику, а не на научную.
2. Формируем правила визуализации и информационные связи: как объект отображается в меню, поиске, фильтрах и фасетах, чтобы не было дублирования или рассинхронизации. В карточке сущности могут быть указаны обе принадлежности, но навигация использует только основную.
3. Фиксируем конфликты и владельцев решения: кто принимает решение, когда пересматривается структура, где фиксируются комментарии и примечания.
4. Документируем принципы разрешения конфликтов и исключения, чтобы разные подсистемы (поиск, рекомендации, SEO) пользовались единым источником правды.

7. Пример визуализации базы данных

По итогу работы над информационной архитектурой обычно создаются спецификации API и дизайн БД. Про API здесь говорить пока рано, а вот про БД уже пора.

Ловите пример того, как может выглядеть простенькая база данных в виде ER-диаграммы:

Здесь учитывается почти всё:

• По типу соединения можно понять тип связей. Например, от users.id к orders.user_id соединение начинается одной линией, а заканчивается несколькими, разветвлением — это связь однин-ко-многим (1:N).
• Иконка «ключика» возле названия поля обозначает первичный ключ (primary key), который уникально идентифицирует каждую запись. А иконка «заметки» говорит о том, что у поля есть дефолтное значение.
• Если возле названия есть иконка «ссылки», то это внешний ключ (foreign key), и от него почти всегда будет связь 1:N к источнику. Например, от того же orders.user_id к users.id.
• Две буквы «NN» в конце каждой строки — это «NOT NULL», поле не может быть пустым. Та самая обязательность из таблички, помните?
• Буква «Е» в orders.status означает «ENUM» — набор именованных констант. Значение этого поля может быть заполнено только значениями из определённого словаря. В нашем случае статус заказа может быть только pending, paid, shipped, delivered или canceled.
• Ну а всякие varchar, int, decimal, datetime и другие — всего лишь типы данных, которые хранятся в этом поле.

Так нафига вообще тогда информационная архитектура, если можно сразу пилить ER-диаграммы и не париться? Да потому что они описывают только один слой IA — слой реализации хранения данных (в самом начале статьи мы об этом говорили). Огромный пласт информации, накопленной грамотным подходом к IA, здесь не учитывается. Примеры, политики заполнения и мультиязычности, правила валидации, источники данных и куча всего остального.

Так что не ER-диаграммами едиными.

8. Что дальше

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

Подписывайтесь на канал, там будут все новости.

• Все статьи цикла:
• Информационная архитектура: краткий экскурс
• Информационная архитектура: пример и типизация
• Информационная архитектура: сущности (теория) (вы здесь)
• Информационная архитектура: сущности (практика, vol.1)
• Информационная архитектура: сущности (практика, vol.2)
• Информационная архитектура: модели (coming soon)
• Информационная архитектура: практические советы (coming soon)