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

На третьем месте по критической важности в нашей Базе Знаний находится описание модели данных. Важно подчеркнуть: речь идет не о технической схеме базы данных (не о DDL-скриптах с типами полей и индексами), а о концептуальной и логической модели. Если ядровые процессы — это «как» система работает, то модель данных — это «о чем» система работает. Это универсальный язык, на котором говорят все компоненты системы и который понимают все участники команды: от бизнес-аналитика до разработчика и тестировщика.

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

RESTful API, методы сервисов, сообщения в очереди — все они оперируют сущностями и их состояниями, описанными в модели данных. Четкая модель позволяет проектировать непротиворечивые, логичные API-контракты. Новый разработчик, взглянув на модель данных, быстро понимает, с какими объектами ему предстоит работать и как они связаны. Это сокращает время на погружение в проект на порядок.

Что должна содержать модель данных: 1. Диаграмма сущностей и связей - это наглядное графическое представление модели. Используйте нотацию, понятную команде. Диаграмма должна быть актуальной и доступной в понимании. 2. Описание каждой сущности: Какую бизнес-концепцию или объект реального мира она представляет? Какие основные состояния есть у сущности? 3. Для ключевых атрибутов сущности важно описать их бизнес-смысл, а не технический тип. 4. Описание связей - Важно объяснить природу каждой связи между сущностями с точки зрения бизнес-логики. Самое частое - это один ко многим. 5. Бизнес-правила - Это правила целостности, которые не всегда можно выразить на диаграмме. Например, это могут быть ограничения на изменения состояний, или удаление сущностей.

Модель данных в Базе Знаний — это семантический мост между бизнес-логикой (процессами) и технической реализацией (кодом и БД). Ее наличие гарантирует, что все участники проекта имеют единое и непротиворечивое понимание того, какие данные живут в системе и как они соотносятся друг с другом. Это — язык, на котором говорит ваша система.