Здравствуйте, stasukas, Вы писали:
S>Под сервисом я понимал некоторый набор операций, специфичный для сущности или группы сущностей, но никак не технологии. Кто мешает сделать некоторый набор таких сервисов (лучше их назвать бизнес-сервисами) и делать необходимые агрегирующие надстройки? Если есть необходимость отключить часть функциональности, то в агрегирующих сервисах мы можем сделать необходимую настройку или поставить dummy stub вместо этого сервиса.
S>

Понятно. С другой стороны, не вижу леса за деревьями. Честно говоря, не вполне понятно, какое отношение модель клиент-серверного взаимодействия и aggregation layer имеет к вопросу проектирования бизнес-модели.

Я обдумывал архитектуру конфигурируемой erp, в которой есть базовая часть, специализированные модули и пользовательская конфигурация. И видел в этом две проблемы, которые нужно решить, чтобы все было хорошо:
1. разработка модулей — т.е. как модулей, а не как отдельных различных конфигураций одной системы.
2. накат новых версий базовой конфигурации и модулей так, чтобы не страдала клиентская конфигурация. сейчас ни 1C, ни Axapt'у, ни SAP нельзя кастомизировать не попортив базовую версию. накатить после этого расширения функциональности от поставщика очень сложно. т.е. можно поставить новую version 4.2.1.13, но нельзя обновить покуроченную конфигурацию CRM Solutions 9 на CRM Solutions 10.

IMHO, собственно это и есть вопрос проектирования сущностей, их представлений и обработки событий.

P>>вот этого я совсем не понял. "одновременная работа с разными сущностями" "позволит выявить и разрешить" — это как?
S>Мы всегда можем сделать любой из видов блокировки в своем приложении на уровне сущностей или специфических свойств сущностей (т.е. как бы на уровне представления таблицами). Таким образом мы можем независимо работать с разными сущностями при редактировании различных данных (относязихся к различным сущностям), но и сможем разрешать конфликты при изменении одних и тех же данных.
S>Например, один пользователь редактирует Customer, а другой CRMCustomer. При этом, если изменения не пересекаются по сущностям, то конфликта нет, а если пересечение есть (изменения в Customer), то возникает конфликт, который мы решаем стандартным выбранным образом.

понятно. в принципе, да, можем. просто я пока сторонник offline решений. хотя я все время работал над online системами, я всё время обдумываю, как бы сделать всё offline.

S>У меня такое видение данной проблемы. Если кто-нибудь видит ее по другому, то я рад был бы выслушать и других.
S>Если есть желание, то могу объяснить более подробно на ближайшей RSDN UG или MDNA UG в Москве.
желание есть.