Размышления про DDD и ORM
Извините, что я опять о том же самом...
Просто хочется с кем-то обсудить...
DDD – это который domain-driven design от Эрика Эванса. Который я читаю и все никак не дочитаю. Но по мере чтения пытаюсь мысленно применить к близкому для меня проекту.
А близкий для меня проект – это учетная система, отраслевой ERP. И вот к нему почему-то DDD никак не применяется.
У меня создается стойкое ощущение, что DDD применим для определенного круга задач. Примером могут быть:
· игры и симуляторы,
· программы для конструирования, редактирования, верстки и дизайна,
· программы автоматизации технологических процессов
И прочие программы, общим для которых является то, что:
· основные вычисления производятся над данными в оперативной памяти;
· исторические данные не так важны, как последнее состояние;
· другими словами, не производится массовых операций над историческими данными (типа статистики или отчетов);
· объекты могут читаться из постоянной памяти в оперативную выборочно (т.е. не все), но целиком (т.е. не частично).
И вот здесь же хочется упомянуть ORM, который тоже, как мне кажется, «заточен» именно под такие типы приложений, когда ставится задача сохранить текущее состояние сложной совокупности объектов из оперативной памяти, где с ними производится основная работа, в постоянную память для хранения ее там между сеансами работы.
Отличием же систем учета (ERP) является то, что оперативные данные не так важны и сложны, как их историческая совокупность. Даже автоматизация workflow или document flow не так уж сложна, чтобы моделировать ее в виде объектов предметной области и держать постоянно в оперативной памяти для ускорения работы над ними. Львиная доля задач состоит в том, чтобы занести в систему документ с первичными данными. Далее, каждый объект, каждый документ перестает быть интересным сам по себе как единая целая сущность. Смысл имеют огромные множества комбинаций его частей. Сводные отчеты по количествам, суммам, характеристикам, типам, свойствам и условиям. И все это собирается по большому множеству данных, собранных и хранимых за определенное время.
Пример. Сущность «Сотрудник». Имеет множество «полей» или «свойств», как то: полное имя, паспортные данные, контактные данные, табельный номер, отношение к отделу и прочее. Возможно, возраст, оклад, рост, вес. В общем, много всяких свойств. В совокупности этот объект может быть интересен только при редактировании справочников. Это малая толика работы системы. Большую же часть времени будут требоваться всевозможные комбинации его свойств. Чаще всего имя. Иногда должность и отдел. Но все эти данные будут частью другой сущности, типа отчета или списка.
В этой ситуации я просто не представляю себе оптимального способа выбора из постоянной памяти только
нужных полей, если только не ценой трафика. Либо не ценой растраты памяти на то, чтобы все объекты все время висели в памяти в полном своем объеме.
Так что для учетных систем, я думаю, стоит все таки оставить программирование бизнес-логики на языке для массовых операций над данными – языке SQL. Переносить бизнес логику на объектный язык (Java) может стоить слишком дорого.
