Здравствуйте, stasukas.
Спасибо, конечно, за ответ, но все это тривиальные вещи. Я спрашивал немного о другом.

P>>В терминах ERP, нужно получить несколько различных конфигураций для разных задач.
P>>В случае 1с это будут фактически разные программы и их придется сшивать вручную.
P>>В случае SAP это модули.

S>Данный вариант оптимально было бы делать на основе расширений (plugin). Пишется один раз интегрирующий интерфейс, который в соответствии с конфигурацией загружает необходимые модули расширения. Каждое расширение будет иметь свой уникальный набор функциональности (обычно интерфейсная часть). Написание модулей расширения тогда будет относительно независимым. Так же повысится возможность повторного использования.

Хорошо. Рассмотрим следующую ситуацию. У нас есть базовая конфигурация, miniBasis, к которой создаются модули CRM и WMS. Такие модули можно делать в виде plugin. Это будет касаться пользовательского интерфейса. Что насчет дополнительных полей в сущности Customer? Как добавить CRM возможности, чтобы ими было удобно пользоваться (а не через Advanced->CRM Options)? Как обеспечить интеграцию модулей, т.е. расширение фич WMS в присутствии модуля CRM?

S>Любое окно может иметь стандартную часть, а необходимая функциональность достигается за счет дополнительных расширений данного окна. Например, окно с табами, где есть закладка "основные параметры", а в зависимости от вызываемого контекста загружать дополнительные расширения окна, которые добавляют свои закладка типа "CRM specific".
S>Пример такой архитектуры можно посмотреть здесь

Автор: stasukas
Дата: 12.10.05

. Если посидеть с напильником, то можно за некоторое время заточить под себя и использовать в дальнейшем (это, чтоб не выдумывать самому велосипед )

Да, нормальный известный пример. Но он больше касается automation, т.е. управлением извне UI и функциональностью приложения. Программировать под такую систему можно, но не очень удобно. Куда девается RAD? Мы уже не можем просто так визуально создать меню в design time.

S>Что касается общей архитектуры решения, то использовать модульную интерфейсную часть, которая будет общаться с бизнес-логикой (ES, WS или другие технологии), а та в свою очередь с БД.

Как быть опять же, если после года работы клиент решил доставить себе еще один модуль? (эволюция схемы, незаполненные новые параметры, накат модуля на кастомизированную базовую версию, обновления)...

P>>Зная заранее, что все системы разрабатываются нами, пусть и в разное время, что можно предложить в плане теории и практике разработки и интеграции таких штук?
S>Если система пишется с нуля, то лучше с самого начала писать модульную расширяемую систему. Если уже есть какие-то разработки, то можно их интегрировать с помощью интегрирующего ПО (как самописного, так и с помощью вещей типа BizTalk).

Это всё понятно.