Здравствуйте, stasukas, Вы писали:

S>Возможно, что я сильно завяз в xml, поэтому для меня не вызывает особой проблемы обеспечение передачи относительно разнородных данных одним пакетом. В этом и есть та гибкость, которая необходима при общении PL и BLL. А отсюда вытекает и расширяемость.

Я сам передаю данные в xml. Он хорош. Вопрос — при чем тут xml? Aggregation можно сделать как угодно, но не все же задачи сводятся к передаче данных Я сейчас не смотрю ни на таблицы, ни на DataSet, ни вообще на DTO. Оставим за рамками aggregation level. Вопрос в том, как расширять сущности.
Возьмем 1С:
Клиент запускает конфигуратор и добавляет новые атрибуты к справочникам. пишет код. после этого накатить обновления конфигурации проблематично.

Возьмем SAP:
Нужно добавить флажок к единице учета. Клиент берет поле Reserved1 в таблице и юзает под себя. Потому что заводить новую колонку нехорошо — может быть конфликт имен.

Мне кажется, что можно решить такую проблему, если делать следующие вещи:
— любые расширения сущностей делаются как создание новой сущности, агрегирующей старую. это мы уже обсудили. контроль доступа и прочее делается на уровне каждой из сущностей своими службами. Рассмотрим модуль CRM. Он расширил Customer полями Debt и прочее. Вроде как теперь во всех используемых сущностях должен быть CRMCustomer. Принципиально никто не мешает нам нагенерить заново все классы БО, чтобы они работали с CRMCustomer. Иногда нужно из модуля CRM нужно работать с WMSCustomer. Этого WMSCustomer также можно сгенерить специально под модуль CRM, вроде как proxy. Теперь можно будет спокойно апдейтить базовую конфигурацию. Старый CRM просто не будет знать о новых сущностях, полях и методах. Если мы не используем наследвоание, references и т.д., то проблем нет.
Просто это означает, что если кто-то захочет покопаться в CRM, для него нужно отпачковать еще одну версию всех сущностей. Тогда можно будет апдейтить и CRM модуль тоже. думаю так.

P>>Я обдумывал архитектуру конфигурируемой erp, в которой есть базовая часть, специализированные модули и пользовательская конфигурация. И видел в этом две проблемы, которые нужно решить, чтобы все было хорошо:
P>>1. разработка модулей — т.е. как модулей, а не как отдельных различных конфигураций одной системы.
S>Пожалуйста — относительно независимые бизнес-сервисы. общая конфигурация системы
да, почти так.

S>Почему нельзя расширять конфигурацию таких систем? Строго определенные DTO, которые не могут независимо изменять структуру. Если передавать сущности с помощью xml, то не будет возникать проблем с расширением функциональности каждого бизнес-сервиса.

не только поэтому. см. выше, а кроме того есть еще методы и формочки. кто-то залазит в код метода и меняет его. двигает на формочке контролы и меняет их цвет.