Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

[mazzy]

Цитата:

Сообщение от mazzy

Как вести разработку с минимальными в долгосрочной перспективе трудозатратами
в условиях, есть куча унаследованного кода И часть кода закрыта от изменения,
а платформа предоставляет систему событий и подписок?

Что должен внести в код вендор?
Какие техники и приемы может применять ISV/партнер/клиент?

=========================
пока прозвучали варианты:
= снять ограничения и писать поверх (лицензионным или нелицензионным способом)
= копировать существующие объекты
= врезаться в существующие event'ы.
=== при этом ожидается что будет дублирование кода
=== один из крайних вариантов - полное дублирование - врезаться в событие "загрузка системы" и после этого не отдавать управление стандартному приложению

ограничения, насколько я понимаю:
= в закрытые объекты новые евенты добавить нельзя
= подписчик может не иметь доступа к паблишеру события, поэтому часть информации возможно придется передавать через глобальные переменные

Предлагаю на обсуждение еще один вариант, который проявился в двух ветках:
Какие библиотеки используют разные веб-клиенты Dynamics?
Как достучаться из веб-приложения к акс2012, акс2009? Сервер OData?
Вариант - небольшие приложения, которые взаимодействуют с Аксаптой.

• В последнее время ориентир на веб-приложения. Даже приложения для мобильных платформ все ближе и ближе к обычным веб-приложениям.
• Сам майкрософт в своей поставке использует различные подходы-библиотеки для веб-клиентов.
• Сам майкрософт в своей поставке реализовал бизнес-логику вне Аксапты
• Процесс выделения "микросервисов" в майкрософте будет продолжаться и дальше

Поэтому, возможен такой путь:
Отдельное приложение может использовать DataEntity (AIF, DIXF) для обмена данными с Аксаптой, но бизнес-логику в своей области может реализовывать самостоятельно.

Да, тут теряется масса маркетинговых преимуществ типа "единая и всегда целостная база данных", "актуальные данные" и прочие лозунги вчерашнего дня.
Но появляются другие. Типа "гибкость" и т.п. )

Кроме того, отдельные приложения вполне в русле облачного направления. Ценообразование в облаке устроено так, что каждый сервис оплачивается отдельно маленькой денюшкой. Поэтому, с точки зрения МС, много маленьких взаимодействующих приложений-серверочков вполне хорошо генерирует выручку.

Да, приложения вполне могут хостится не на windows-стеке, а на других серверах и платформах. Но в целом, Майкрософт может постараться сделать платформу и стек удобнее.

Да, отдельные приложения - плохо с точки зрения архитектуры.
Но отдельные приложения - лучше, чем дублировать существующие объекты или снимать ограничения.

Что думаете?