IT wrote:
> _>Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.
> Да. Упрощается мапинг.
При этом либо кривеет модель предметной области (что понижает
понимабельность кода, расширяемость и простоту поддержки) либо модель
данных (что понижает производительность). Ищите, друзья, золотую
середину: крайности как правило приводят к геморрою

По всему остальному. Человеку нужно проанализировать общение с компанией
за несколько лет, потом поднять ее счета и т.д. Я продозреваю, что это:
1) большой объем данных
2) он носит исторический (не рабочий) характер (то есть этих данных в
памяти для текущей работы нет), скорее всего на них нет и модели классов

Из этого делаем совершенно тривиальный вывод, что имеет смысл вынести
этот расчет в БД, как говорится "move processing to data, not data to
processing". Вот вопрошающий и принял это решение.
Теперь давайте забудем о мепперах, ибо это понятие всех путает. Меппер
предназначен для того, что ОТОБРАЗИТЬ данные БД в модель предметной
области. Сам объект остается В ПОЛНОМ НЕВЕДЕНИИ о существовании этого
меппера. Об этом знает прикладной код, который загружает объект по
необходимости, сервисный слой (как у IT) и прочая. БО ничего не знает о
DAL, совсем, я думаю и о сервисном слое тоже, разве что о реестре
каком-нибудь, но это отдельная песня. Если LL, то пожалуйста через
посредников, обертки и т.п.: не надо захламлять объект предметной
области, это не его задача, а вопрос реализации оптимизации.
Далее. БО нужна эта функциональность (для каких-нибудь вычислений)? Если
да — то я уже предложил дать ему стратежку, которая будет принадлежать
DAL, ее интерфейс будет определен в модели предметной области и от нее
будет зависеть этот DAL (а он и так зависит, иначе как мапить). Если нет
— вынеси это в отдельный класс DAL, накрой сервисным слоем и пользуйся:
так будет понятнее и спокойнее всем.
Есть конкретные вопросы — милости просим. Тащить эти исторические данные
в память, организовывать для них модель классов не сильно хорошо ИМХО.