Разработка решения, которое может иметь потенциально бесконечные классы с настраиваемыми бизнес-правилами - PullRequest
Новая
       3

Разработка решения, которое может иметь потенциально бесконечные классы с настраиваемыми бизнес-правилами

2 голосов
/ 18 октября 2011

Я работаю над "умным" приложением для отслеживания проблем, которое должно определить, может ли конкретная проблема быть подана в заявке, прежде чем фактически разрешить отправку.

Проблема проектирования, с которой я сталкиваюсь в настоящее время, заключается в том, что у меня может быть много разных типов «представляемых» проблем, каждая из которых имеет свою собственную уникальную бизнес-логику, которая определяет, может ли проблема действительно быть представлена. Из моих проектных заметок у меня следующие условия:

  1. Поддерживает несколько проблем (неизвестное число, теоретически может быть бесконечным)
  2. Каждая проблема напрямую связана с конкретной отправкой (т. Е. Пользователь выбирает свою проблему, а затем ему предлагается выбрать / ввести перевозку, с которой он имеет проблему)
  3. Каждая проблема имеет свои собственные проверки / бизнес-правила (данные предоставляются отгрузкой), которые определяют, может ли проблема продолжаться. Примеры будут:
    • Если проблема связана с требованием о возмещении ущерба, груз должен быть получен в течение 60 дней.
    • Если проблема связана с отменой или возмещением, статус доставки не может быть доставлен.

Идея почти похожа на приложение обработки страховки, но вся информация уже предоставляется путем запроса отгрузки, вместо того, чтобы полагаться на ввод пользователя (например, мне не нужно спрашивать, когда отправка была отправлена, я могу спросить объект отгрузки для его PickupDate), и есть только два результата: 1) У проблемы может быть открытое дело, или 2) Нет, у проблемы не может быть дела (так называемый вариант "неудачи"). С архитектурной точки зрения, даже если я использую какой-либо шаблон STRATEGY, который может поддерживать несколько типов проблем, для каждого производного типа проблемы потребуется создать собственный класс. Например, мне понадобятся DamageClaimIssue и CancellationRequestIssue, и кто знает, что еще; это кажется громоздким на стороне разработчика, так как новые типы могут быть добавлены почти по прихоти и требуют от разработчика раскрутки нового производного класса и реализации логики проверки, а затем перекомпиляции и повторного развертывания.

Является ли использование Стратегии лучшим способом решения такой проблемы, или я что-то упускаю? Теоретически я хотел бы сделать архитектуру достаточно общей, чтобы учесть различные проблемы (я знаю, что их будет больше 2-3, я просто не знаю, какими они будут в точности), но я не хочу останавливаться на путь к наличию некоторого монолитного механизма рабочего процесса, использующего XML или аналогичный, который позволяет определять вещи на лету с помощью динамической логики. Я должен использовать стандартные библиотеки .NET 3.5 (то есть ничего подобного WCF или Workflow Foundation).

Какие-либо предложения или указатели, чтобы установить меня в правильном направлении?

Ответы [ 3 ]

2 голосов
/ 18 октября 2011

Первое, что нужно задать здесь: кто будет отвечать за определение новых типов проблем в вашей системе?

Когда я вас правильно понял, это должен быть пользователь (возможно, не каждый пользователь, а "опытный пользователь"), а не разработчики вашей системы. Таким образом, вам нужен общий тип проблемы или несколько типов проблем, которые не должны быть слишком конкретными и могут быть уточнены параметрами, указанными пользователем. Относительно проверок / бизнес-правил: вы можете попытаться определить DSL для того, в котором пользователь может определить эти правила самостоятельно. Правила, определенные в этом DSL, могут быть сохранены как часть определения типа, возможно, в базе данных, поэтому код DSL должен интерпретироваться вашим механизмом, когда применяется проверка.

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

0 голосов
/ 19 октября 2011

Я бы предложил использовать систему бизнес-правил, такую ​​как drools в Java.

http://droolsdotnet.codehaus.org/

0 голосов
/ 19 октября 2011

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

Недавно мы использовали порт .Net инструмента IBM под названием iLog; Я не могу сказать, что это было безболезненно, но это сделало работу. Из памяти пользователи могут редактировать правила в Excel и импортировать в приложение.

Единственный совет, который я должен дать, чтобы все было как можно проще. Вполне вероятно, что где-то произойдет элегантный «беспорядок» правил и т. Д. (Которые сами по себе будут сложными), убедитесь, что вы сделаете все остальное как можно проще - вам не нужно сложное / грязное развертывание / обновление / управление версиями ситуация.

...