Бизнес-правила, действительные для определенного периода времени - как управлять упорядоченным образом

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

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

if application.date >"July 17th, 2008"

Каков наилучший способ решения этой проблемы?

Ответ 1

Это выглядит как случай для Цепочка ответственности. У вас будут обработчики для каждого законодательного органа. Сначала вы передаете приложение последнему обработчику. Если он слишком стар, он передает его обработчику предыдущего законодательного органа.

Ответ 2

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

EDIT: Я хотел бы ссылаться на временный объект вместо височного свойства. Это может пролить свет на реализацию сопоставления базы данных.

Ответ 3

Если правила сложны, вам может понадобиться (бизнес-правила). Я не знаю, какие реализации существуют для вашей платформы, но для Java типичный выбор Drools и его Экспертный подпроект. Он определяет язык, специфичный для домена, для определения правил. Обратите внимание, что он может иметь интерфейс для пользователей, не являющихся java.

В противном случае вы можете попробовать что-то вроде Стратегия стратегии - у вас есть список стратегий с двумя методами appliesTo(date) и handle(data). Вы перебираете список и если стратегия применима к дате - пусть она обрабатывает данные.

Ответ 4

На уровне архитектуры существует два подхода к решению этой проблемы.

Во-первых, это ETL-данные для вашего склада до того, как бизнес-логика применяется к данным. Я предпочитаю этот подход.

Иногда, однако, это невозможно сделать - например, бизнес-логика применяется к данным перед ее записью в OLTP (источник, используемый для заполнения хранилища данных), поэтому у вас нет выбора. В этом случае эту проблему обычно называют проблемой быстро меняющейся размерности. (Мое предположение заключается в том, что данные, указанные в вашем вопросе, хранятся в таблице измерений, а не в таблице фактов).

Существует огромное количество комментариев по этому вопросу, доступных в Интернете. Среди этих источников я рекомендую любую из статей (бесплатно) или книги (не бесплатно) Ральф Кимбалл.

Лучший способ согласования быстро меняющегося измерения почти наверняка специфичен; тем не менее, возможно, наиболее распространенным методом является c * создание новой таблицы измерений *, которая хранит данные, применяемые к новой бизнес-логике. Другими словами, у вас в вашей схеме DW будет отдельная таблица измерений для каждого бизнес-правила.