Как использование механизма правил влияет на дизайн, реализацию и производительность приложения?

11

Меня интересует способность правил движков:

  • запускать и перебирать бизнес-логику
  • «бизнес-пользователи» должны выполнять фактическое изменение этих правил, а не разработчики
  • понять бизнес-правила в целом

Кроме того, влияет ли использование механизма правил на качество приложения?

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

enonu
источник

Ответы:

5

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

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

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

Все началось с того, что могли использовать только определенные люди, такие как разработчики или администраторы. Интерфейс был неуклюжим, но его можно было использовать, если вы знали, что делаете. Но к тому моменту, когда продукт был близок к завершению, логика бэкэнда движка правил пригодилась, и наша команда дизайнеров предоставила ему красивый, ориентированный на клиента пользовательский интерфейс.

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

jmort253
источник
1
Я бы добавил, что бизнес-пользователям стоит потратить время на изучение интерфейса правил. Интерфейс будет проще для пользователей, но на его изучение уйдет определенное время и усилия. Им не следует ожидать чего-то магически понятного.
9000
@ 9000 - Очень хорошая мысль. Я видел это в моих собственных проектах. На самом деле, это часто все еще включает в себя обучение для повышения скорости работы пользователей, а также определенный аспект «продажи» интерфейса пользователям и демонстрации им той ценности, которую он имеет для них.
jmort253
4

Если бы я сделал это, я бы создал язык, специфичный для предметной области, чтобы выразить правила, и, возможно, предоставил бы типам biz пользовательский интерфейс, чтобы изменить его по запросу. Затем используйте функциональный язык (например, Haskell, Lisp или Erlang) для оценки правил.

Если бы потребовался массивный параллелизм, я бы пошел с Erlang, который очень хорошо справляется с параллелизмом. Использование Erlang будет хорошо масштабироваться от 1 узла до 100 и более.

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

Захари К
источник
3

Я написал приложение на основе WF (Windows Workflow Foundation). Мой начальник (администратор БД) был убежден, что WF может выполнять многопоточность без необходимости планирования параллелизма. Память была разделена полностью, но было так много проблем, что я не могу объяснить это всего лишь в нескольких параграфах, и это только немного связано с вашим вопросом ... поэтому я продолжаю.

Возможность перебора BL:
WF делает это хорошо.
Позволить нетехикам "создать приложение":
WF делает это хорошо, если архитектура работает, а нетехники понимают технические ограничения ... Наши этого не сделали.
Способность понимать бизнес-правила в целом:
есть некоторые надстройки, которые могут выполнять некоторые базовые функции, такие как sharepoint, могут автоматизировать рабочие процессы. Я не попал в эти предметы.
Качество программного обеспечения:
Mediocre. WF не очень хорошо подходил для наших целей, но система была плохо спроектирована, и мои руки были связаны.
Скорость приложений:
Медленный. Кривая обучения довольно крутая как для разработчиков, так и для конечных пользователей. То, как WF разделяла память (домены приложений, если я помню), делало межпотоковое взаимодействие, мьютексы и другие концепции потоков многоплановыми или просто не работало вообще.

В конце концов, я написал прототип, чтобы доказать, что WF терпит неудачу в том, как он был реализован. Я заменил его на обычную многопоточность. Производительность и читаемость кода выросли. Возьмите это с крошкой соли, так как это было мое первое профессиональное приложение WF.

Нетехники могут прийти к выводу, что практически все возможно без участия программиста, что потенциально является большим негативом для всего «пустышки» BL; социологические проблемы, связанные с этим убили проект.

Если бы я мог вернуться и сделать это по- своему : использовать традиционную резьбу и BL-формование, полученное с помощью Decorator Pattern. Я написал подтверждение концепции, которая использовала эти технологии, и она работала хорошо. И отображение BL должно быть обернуто в простой пользовательский интерфейс.
Обновление
Я нашел старый пост, который я написал, работая с проблемами параллелизма. Код показывает, как печать «привет мира» в параллельных рабочих процессах не работает без понимания того, что происходит под крышками (что противоречит всей цели абстракции WF). Модератор MSDN объясняет общий обзор того, насколько параллельные действия действительно последовательны. В заключение он говорит: «Вам нужно прочитать все руководство», чтобы сделать что-то основное. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

Удачи.

P.Brian.Mackey
источник
У меня нет опыта работы с WF, но я всегда держался от него подальше, потому что мой инстинкт инстинкта должен был это сделать. Но я не могу не задаться вопросом, не является ли WinWF просто запаздывающей версией ETL-системы, такой как Rhino ETL, с точки зрения того, что можно сделать с ней так же легко?
Хенрик,
3

У меня был далеко не идеальный опыт подключения Java-кода к движку правил Oracle. Отчасти это может быть связано с неопытностью авторов правил, но с этим я и столкнулся.

  • Мы реализовали наш движок правил как устройство без сохранения состояния. Звонивший должен был собрать все параметры и передать их в двигатель для оценки. Это означало, что если для правила требовалось другое поле данных, все клиенты должны были обновляться. Это сводило на нет рекламируемое преимущество возможности обновлять правила независимо от своих потребителей.
  • Движок опубликовал SOAP WSDL, но он был автоматически сгенерирован из набора правил. Незначительные изменения в правилах могут нарушить договор с потребителями.
  • Двигатель был хорош в оценке правил, но ужасен в том, чтобы сказать нам, почему оценка не удалась. Было трудно передать информативные сообщения об ошибках пользователю.
  • WSDL не подходит для общего потребления. Самый простой набор правил имел WSDL из 14 страниц, который раскрывал внутреннюю часть базы правил. Нам пришлось поместить слой перевода SOA впереди, чтобы представить удобный для бизнеса фасад. Поэтому вместо вызова 100% надежной локальной библиотеки в цикле было два дополнительных сервера. Это не добавляет надежности ни в малейшей степени. Плюс любое изменение в сигнатуре правила было связано с тремя разными командами, которые обновляли код. Не мое определение гибкой!
  • Каждый раз, когда набор правил нуждался в дополнениях, WSDL приходилось обновлять, что означало, что клиенты его больше не понимали. Это привело к добавлению новых конечных точек SOAP для v2, v3 .., что вызвало необходимость обновления правил брандмауэра.
  • Правила были выражены в «структурированном английском», который был легко понятен для простых правил, но почти непрозрачен для сложных правил.
  • Мы никогда не могли найти подрядчиков, которые знали правила авторского языка.
  • Язык правил не реализует массивы, рекурсию или объектную ориентацию. В одном случае единственным способом реализации правила был вызов через электронную таблицу Excel, где правило было реализовано в VB. Зачем беспокоиться?

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

kiwiron
источник