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

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

Получаем вполне стандартную ERD.

Для разработчика ничего необычного. Можно создавать сущности, связи, CRUD и приступать к реализации. Но насколько такая модель соответствует реальному производству? Формально — соответствует. Однако вопросов оказалось больше, чем ответов. Начинаем задавать вопросы — Изделия одной модели, но разных размеров и цветов можно логически объединить? — Да, конечно. Это варианты одной модели. — У таких изделий одинаковая конструкторская документация? — Как правило, да. В документации есть градация лекал по размерам. — А геометрию и площадь составных частей можно получить непосредственно из КД? — Вероятнее всего, да. Нужно проверить формат файлов. — Получается, КД является источником геометрии, а не просто приложением к изделию? — Да. — А составные части изделий одной модели действительно имеют принципиально разную форму? — Обычно нет. Геометрия меняется в зависимости от размера, но базовая конструкция остаётся той же. И вот здесь первоначальная модель начинает меняться. Что получилось после уточнений Модель изделия — самостоятельная сущность с уникальным артикулом, объединяющая изделия общей конструкции. Вариант изделия — конкретное исполнение модели, определяемое размером и цветом. Каждый вариант имеет собственный артикул, формируемый на основе артикула модели и его характеристик. Конструкторская документация — источник геометрии составных частей и информации о поддерживаемых размерах. Составные части — производные данные, формируемые на основании КД, а не произвольные записи, которые пользователь создаёт вручную. Появились и доменные ограничения:

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

Что изменилось? На первый взгляд — просто другая ERD. Но фактически мы изменили подход к данным. Раньше система позволяла вручную создавать изделия и их составные части, даже если они не соответствовали конструкторской документации. Теперь сама доменная модель определяет, какие действия допустимы, откуда берутся данные и какие ограничения необходимо соблюдать. Это не просто нормализация базы данных. Это переход от хранения информации к отражению реальных правил производства. Именно в этом я вижу одну из ключевых задач при проектировании корпоративных систем: не просто перенести существующие процессы в новую программу, а разобраться, почему они устроены именно так и какие правила действительно должны существовать. Иногда пять правильных вопросов меняют архитектуру сильнее, чем несколько дней проектирования таблиц. А у вас бывало, что после разговора с предметным экспертом приходилось полностью пересматривать первоначальную модель? #DDD #DomainDrivenDesign #SystemDesign #ERP #SoftwareArchitecture