Каков наилучший способ для доменного уровня «вызывать» интерфейс

Question

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

Например, предположим, что пользовательский интерфейс выдает запрос на добавление строки в заказ на покупку, а бизнес-правила определяют, что по какой-то причине вам нужен код авторизации. Как уровень домена сообщает это обратно? Вернуть какой-нибудь код ответа, указывающий, что требуется авторизация? Запустить событие «Нужна авторизация» и посмотреть, ответит ли кто-нибудь? Принять какой-нибудь IAuthorizationProvider, который будет реализовывать пользовательский интерфейс?

Все это кажется нормальным, но я борюсь с взрывом возможных вещей, которые могут понадобиться бизнесу. Просто продолжая пример заказа на покупку, что если некоторым элементам нужен цвет? Некоторым нужен идентификатор декларации об опасных материалах? Некоторым нужно простое «это редко, вы уверены?». Список можно продолжать и продолжать. Такое ощущение, что вы решили, что эта информация определенно относится к слою домена. В одноуровневом приложении вы просто откроете диалоговое окно и получите то, что вам нужно. Как вы делаете это в правильно слоистом приложении?

Answer 1

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

Для этого и нужен API. У вас есть несколько вариантов.

1. API бизнес-правил просто перечисляет различные вещи, которые нужны бизнес-правилам. Пользовательский интерфейс отвечает за выполнение полных запросов. Эти вещи не являются динамическими. Это не так, как бизнес-правила меняются случайным образом. Для такого рода вещей есть контроль версий.

2. Исключения работают хорошо. Запрос вызывает исключение, потому что он не завершен. API определяет исключения и способ сделать «полный» запрос свободным от исключений.

3. AuthorizationProvider тоже неплохой план. API должен быть определен, чтобы уточнить, какие запросы выполняются AuthorizationProvider.

"Я борюсь с взрывом возможных вещей ... Список можно продолжать и продолжать". На самом деле это не так. Просто определите соответствующий API, который соответствует проблемной области.

Если - по какой-то причине - вы боитесь, что не можете определить API, то вы не можете определить и проблему.

"А как насчет ...", например, как насчет некоторых предметов, которые имеют цвет или MSDS. А как насчет диалогового окна конфитации?

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

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

У вас не открывается новое диалоговое окно. С отдельным пользовательским интерфейсом и бизнес-правилами вы теперь делаете две вещи:

• Добавить информацию в бизнес-правила;
• Сделайте UI-проверку для этого всплывающего окна.

Вы не добавляете ОГРОМНОЕ количество кода. Свойство бизнес-правила состоит из нескольких строк кода. Проверка пользовательского интерфейса представляет собой строку кода.

Answer 2

Пользовательский интерфейс должен где-то передавать информацию в бизнес-уровень. Проходите ли вы через промежуточный объект, такой как контроллер, или нет. Бизнес-уровень должен определить, находится ли PO в действительном состоянии. Если нет, то верните информацию о том, что не так. Это может происходить либо из вызова метода PurchaseOrder.AddLineItem, либо из метода PurchaseOrder.Validate. Я предпочел бы вернуть информацию проверки из метода PurchaseOrder.AddLineItem, чтобы вы могли определить, что состояние объекта здесь недействительно.

Answer 3

Докладчик или контроллер, в зависимости от того, если вы делаете MVC или MVP, должны знать об этом, а не о домене, домен будет утверждать (защитное кодирование), так как все необходимые значения в порядке, или выдает исключение, а не запрашивает его.

Допустим, вы не указали номер, ваша модель выдает исключение AuthorizationNumberRequiredException, а ваш докладчик обрабатывает его оттуда. Таким образом, ваш домен не связан с докладчиком, он просто выдает ошибки, докладчик должен знать, как с ним справиться, но он не дублирует логику.

Answer 4

Я еще кое-что прочитал и нашел Шаблон уведомлений от Мартина Фаулера, который, похоже, направлен на решение этой проблемы, а также Проверка на основе доменов с помощью Шаблонов уведомлений от Джереми Миллер.

Это описание уведомлений Фаулера, которое описывает в точности то, что я искал:

Объект, который собирает вместе информацию об ошибках и другую информацию на уровне домена и передает ее в презентацию.