Цитата:
Сообщение от
belugin
Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.
...
Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).
А я в терминах бизнеса. Самое важное в этом бизнесе правильно оценить возможность и трудоемкость задачи. Вовремя при этом сделать. Какое-то расхождение до 20% считается приемлимым. С новыми лабиринтами браться за программисткие задачи - это неприемлимый риск уже на стадии оценки.
Все уже придумано. Легион продуктов и фрэймоворков. Наиболее популярный подход с использованием предопределенной файловой структруры. Когда мы просто создаем директории и файлы которые подхватываются системой. При этом базовый код не редактируется. Это уже даже некий стандарт.
В облачных ERP типа SalesForce и NetSuite это API. Так как падение wordpress, Yii и прочих web сайтов это не то же самое как падение ERP. (Хотя для онлайн-магазин это тоже больно, но грабли уже всем известные и потому комфортные).
Цитата:
Пишите код на языке программирования Apex для добавления бизнес-логики или на языке разметки Visualforce (для
создания пользовательского интерфейса). Интегрируйте свое приложение с помощью API-интерфейсов и проводите
проверку подлинности своих внешних приложений.
https://resources.docs.salesforce.co...xtend_code.pdf
Теорeтечески ISV решения для D365FO имеют потенциал. Но они опять таки разумны если делать боковой или паралельный фунционал, не меняя сами существующие процессы. Но с таким сбоку не важно чем, слоями, расширениями или API, снижение рисков за счет функциональной отвязанности.
У меня есть несколько своих вертикальных решений которые я бы в других условиях сделал бы для AppStore D365FO. Но я даже не в состоянии оценить ровно ничего. А на оценке строится бизнес.
Поэтому и раздражаюсь на подобные статьи по сути заманивающие в охотничью яму. В яме тоже конечно можно найти косточку погрызть
