Представляю себе такую систему:

1) Сначала задаются исключительно лоические взаимсвязи между сущностями данных (Отношения)
2) Описываются процессы. Описания практически определяют "сигналы" приводящие в действие те или иные Отношения.

Пример:
1) Отношение @СкидкаVIP: для клиентов, удовлетворяющих такому то условию цена в товара должна уменьшаться на 10%. ФОрмально: @Customers(like...)<->(@ЦенаТовара<=>Обработка(уменьшение 10%))

2) Процессы:
@Формирование прайса(+)@СкидкаVIP
@Отгрузка документа(-)@СкидкаVIP

(+) и (-) означают, что в любом случе Отношение активируется при данном процессе.
Только (+) означает что Отношение явдяется активным
(-) означает что Отношение является блокирующим в случае невыполения.


Результат: управление бизнес логикой из одного места. Наглядность, очевидность управляемость надежность.


Что скажете?

iscrafmдаже в приведенном микро-примере нет никакой наглядности. Откуда она появится в большом проекте?

Блин. Значит я опередил свое время (опять).

Ну во первых Ваше замечание можно трактовать двояко:
1) "Избранный синтаксис не самый удачный как пример наглядного описания сам по себе."
Ну что ж, бывает и хуже.

2) Вы предполагаете что именно в тексте (плоском) и будет существовать проект.

Объясняю...

конечно же Проэкт не существует прсто как текст. как уже давно принято метеданные - это база данных со всеми Master Detail и RelativePointOfView (относительная точка наблюдения) - фичами.

В таком случае
1) можно выбрать Сущность @Customer и посмотреть все отношения в которых она участвует.
2) Выполнить поиск по Сигналам Включения Отношений
и так далее..

что касается синтаксиса.... ну не знаю.

iscrafm Bely FarusБлин. Значит я опередил свое время (опять).
......
что касается синтаксиса.... ну не знаю.Какой велосипед вы пытаетесь изобрести?
Язык описания бизнесправил?

Их масса... начиная от моделирования процессов, заканчивая встренными языками ERP систем.
+1

Я шутил насчет времени. А тема как раз имеет вид вопроса.
Языков описания масса. Что скажете про этот конкретный.
Ответ такой знаете...
Например я спросил - вот я придумал такой вид сыра.
Ответ - сыров очень много.
Знаете всего много - но ВЫ то конкретно все еще пишете через do while и for.
И потом моя цель - не изобрести чего то, а как раз найти в той куче в которой "всего много" - то что уже соответсвует именно такому способу описания. Это было в вопросе темы.

iscrafm Farus
Знаете всего много - но ВЫ то конкретно все еще пишете через do while и for.
И потом моя цель - не изобрести чего то, а как раз найти в той куче в которой "всего много" - то что уже соответсвует именно такому способу описания. Это было в вопросе темы.
я конкретно давно не пишу. Системы делаю немного другим способом . Намного быстрей чем заниматься языками. То о чем Вы говорите просто представляется очередной нотацией. В C дефайнов наделайте и получите свою задумку.

Еще раз: Би Си дефайнов?
Может ссылку дадите?

Объясняю чем вызвана потребность: система которую эксплуатируем изобилует условиями ограничениями и частынми случаями. "Нарисованный образ" - кристаллизовался в мечтах избавления от ада этих if else loop и прочей хренотени на PL/SQL/

Системы есть... Какие?? Конекретно.
Предлагают OEBS, но это не то. Там насколько мне известно такоего нет.

По ERP языкам ИЗВИНИТЕ, - это языки сурово процедцурные. Подражатели C++, Java. Взять ту же Аксапту и 1С. Не надо мне авторитетно (с пузатым солидняком) указывать на вещи к вопросу отношения не имеющие.

Системы есть... Какие?? Конекретно. Кроме IscraFM.

Например: есть система спроектировання, забитая под завязку бизнес логикой (в течение нескольких лет)... работающая.
И теперь я хочу проинспектировть её. Я задаю её базе метаданных вопросы и получаю ответы:

1) А скажи ка мне (система) какие ограничения действуют в зависимости от типа клиента - иными словами - выведи мне полный список бизнес правил на которые которые действует такая сущность как ТипКлиента.

2) А скажи ка мне система какие ограничения (подверженные влиянию этой сущности бизнес-правила) остаются активными если Тип клиент принадлежит такому то множеству значений.

3) А скажи ка мне система в каких бизнес правилах и как участвует такая сущность как код товара или категория товара...

и так далее...

malyavaпоищите в инете 'системы искусственного интеллекта'

А еще лучше поискать "Методы вызова инопланетян".

:-)

ModelRТехнологии, основанные на исчислениях, а не алгоритмах существуют. Тому же ЛИСПу и основанных на нем системах не один десяток лет.

Главное,ИМХО, почему не внедряются в бизнес-практику:
очень сложно отлаживать базу правил,
очень сложно организовать изменения.

А вот большинство маршрутизаторов, а также реализации сетевых протоколов давно работают на правилах...
Действительно почему не внедрояется в бизнес практику??

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

Логик Farusуправление бизнес логикой из одного места
так и есть . зачем что-то менять? :))

Где есть? В OEBS или в 1С?

_мод Farus1) Сначала задаются исключительно лоические взаимсвязи между сущностями данных (Отношения)
Для начала придумайте способ описания самих сущностей. Когда придумаете - плиз в студию.

вот что такое для вас docl? ничего. а для нашей базы Оркал это таблица = сущность.
все зависит от среды в которой эта сущность существует.
пусть сущности будут - все равно что таблицы. с форин кеями и прочей атрибутикой.

самый больной вопрос (в моей практике) - это инспекция, инвентаризация и соблюдение непротиворечивости в системе бизнес-правил.

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

Хотя бы для примера такое посмотреть.

Bely FarusЧто скажете?Вот еще почитайте .
Будет занятно.

Domain Driven Design.
Что понимается под Domain?

Интресно, это оно?

BRI