Vladimir BaskakovЕсли включать код юзера в проект - размывается зона ответственности и соответственно - кто покрывает убытки в случае проблем.ТС говорил "Я не уверен, что сейчас буду заниматься проблемой защиты от самого себя"

для случая, когда и скрипты, и основной код пишет 1 программист (или 1 контора) - вариант, думаю, годный

другой возможный случай - дешевая и сердитая система/внедрение, рассчет на простоту и краткость пользовательских скриптов, но сторонний программист наворотил сложностей и не справляется с отладкой - тогда за отдельно оплачиваемую работу берется разработчик системы и только тогда скрипт (временно, для отладки) становится частью проекта

в простых случаях скрипты можно править изнутри программы, по нажатию спец. кнопочки они попадут в папку с исходниками проекта (далее - перекомпиляция и продолжение отладки)

в сложных случаях можно править скриптовый *.cs в проекте, по окончанию придется переносить правки в "исходные" скрипты внутри программы

Vladimir Baskakovможно дать юзеру заменять dll в которой ф-ции по перечню которые основной код дергает в триггерных точках..... и пусть хоть на чем хотят на том и кастомизируют.не проверял, но и такая возможность кажется реальной - то есть юзер в своей студии спокойно отлаживает код своих сборок, загружаемых основной программой

Petro123, а Microsoft ClearScript пройдет?
IronPython? MoonSharp(Lua)?

Vladimir Baskakovдля этого случая не особенно понятно, зачем нужны именно скрипты.я в основном про случай "одна контора, но люди разные".
иногда внедрением у заказчика занимаются отдельные от программистов внедренцы, иногда они это делают географически далеко от программистов и без доступа к коду и среде разработки.

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

случай с одним программистом тоже не особенно понимаю, но и тут могут действовать те же соображения, что и с внедренцами.

в общем и целом, случаи с частыми и долго длящимися изменениями бизнес-логики более тяготеют к вводу возможностей скриптования, чем "один раз написали - 10 лет используют" и чем более изменчивая БЛ - тем сильнее.

Petro123,
как я понял, вы тоже против скриптования как такового. То есть ТЭО не пройдет ни один вариант?

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

дополнительные "головняки" основным программистам или конторе в целом, которые может принести такое решение - опять же проблема другой области - организационная.

Vladimir Baskakovвнедрение скриптовой технологии не факт что сделает жизнь беззаботнее со всех сторон....действительно, бывают такие проблемы

мне кажется, все проблемы возникают из-за сложности информационной системы или даже из-за роста этой сложности. от этой сложности никуда не деться, как не распихивай её по разным углам или не размазывай тонким слоем.

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

Petro123вопросы устойчивостичем монолитнее - тем проще. да, тут явный минус у скриптов.

Вопросы единства ответственности - тоже минус скриптов.

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