域层“调用”到UI的最佳方式是什么

Question

当您的域图层或业务层（无论您想要调用它）与UI完全分开时，它如何收集完成请求所需的信息？

例如，假设UI发出向采购订单添加行的请求，业务规则由于某种原因确定您需要授权代码。域层如何进行通信？返回某种响应代码表明它需要授权？发起“需要授权”活动，看看是否有人回应？接受UI将实现的某种IAuthorizationProvider？

所有这些看起来都没问题，但我在努力应对业务可能需要的大量事情。只需继续购买订单示例，如果某些商品需要颜色该怎么办？有些需要危险材料声明ID吗？有些人需要一个简单的“这很少见，你确定吗？”。列表可以继续下去。感觉就像决定你需要这个信息肯定属于域层。在非分层应用中，您只需弹出一个对话框即可获得所需内容。你是如何在适当的分层应用程序中做到的？

Answer 1

“......业务规则确定您出于某种原因需要授权代码。域层如何与此进行通信？”

这就是API的用途。你有几个选择。

1. 业务规则API只列出业务规则所需的各种内容。 UI负责完成请求。这些东西不是动态的。它不像业务规则随机变化。这种事情有版本控制。

2. 例外情况很好。该请求引发异常，因为它不完整。 API指定例外以及如何使“完整”请求免于例外。

3. AuthorizationProvider也不错。将定义API以阐明对AuthorizationProvider执行的请求。

“我为可能发生的事情而奋斗......这份名单可能会继续下去。”实际上，它没有。只需定义适合问题域的适当API即可。

如果 - 由于某种原因 - 您担心无法定义API，那么您也无法定义问题。

“但是......怎么样？”例如，有些颜色或MSDS的物品呢？如果有一个混淆对话框呢？

1. 颜色 - 或其他详细信息，如MSDS。首先，该模型具有“需要颜色”设置。 UI只是检查是否需要颜色对话框。只有有限数量的这些，所有这些都是你正在解决的问题的一部分，所有这些都可以枚举。

2. 确认稀有事物。同样，业务规则具有“需要确认”属性或方法。用户界面检查这一点。只有有限数量的这些，所有这些都是你正在解决的问题的一部分，所有这些都可以列举。

您不会弹出新对话框。使用单独的UI和业务规则，您现在可以做两件事：

• 将信息添加到业务规则中;
• 让UI检查弹出对话框。

您没有添加大量代码。业务规则属性是几行代码。 UI检查是一行代码。

Answer 2

演示者或控制器，取决于你是否应该知道MVC或MVP，而不是域，域将断言（防御性编码）是所有需要的值，或者抛出异常，而不是要求它。

因此，假设您没有提供数字，您的模型抛出AuthorizationNumberRequiredException，然后您的演示者从那里处理它。因此，您的域未与演示者耦合，它只是抛出错误，您的演示者必须知道如何处理它，但它不会重复逻辑。

Answer 3

某处的UI必须在某个时刻将信息传递到业务层。您是否正在经历一个中间对象，如控制器。业务层需要确定PO是否处于有效状态。如果没有，那么返回说明错误的信息。这可以从PurchaseOrder.AddLineItem方法调用或者可能是PurchaseOrder.Validate方法进行。我倾向于从PurchaseOrder.AddLineItem方法返回验证信息，以便您可以确定对象状态是否无效。

Answer 4

我已经做了一些阅读，并找到了来自Martin Fowler的Notification Pattern，它似乎是为了解决这个问题以及杰里米勒的Domain Centric Validation with the Notification Pattern。

这是福勒对通知的描述，它描述了我正在寻找的内容：

  

一个对象，它收集有关域层中错误和其他信息的信息，并将其传达给演示文稿。