当您的领域层或业务层（无论您想怎么称呼它）与您的 UI 完全分离时，它如何收集完成请求所需的信息？
例如，假设 UI 发出向采购订单添加行的请求，并且业务规则确定您出于某种原因需要授权代码。域层如何将其传达回来？返回某种响应代码，表明它需要授权？触发“需要授权”事件并查看是否有人响应？接受 UI 将实现的某种 IAuthorizationProvider？
所有这些看起来都还可以，但我很难处理业务可能需要的大量可能的事情。继续采购订单示例，如果某些商品需要颜色怎么办？有些需要危险材料申报ID？有些人需要一个简单的“这很罕见，你确定吗？”。名单可以继续下去。感觉就像决定您需要此信息绝对属于域层。在非分层应用程序中，您只需弹出一个对话框并获得所需的内容。您如何在适当分层的应用程序中做到这一点？
【问题讨论】：
标签： architecture
“...业务规则确定您出于某种原因需要授权码。域层如何将其传达回来？”
这就是 API 的用途。您有多种选择。
业务规则 API 仅列出业务规则所需的各种内容。 UI 负责发出完整的请求。这些东西不是动态的。这不像业务规则是随机变化的。这种东西有版本控制。
异常运行良好。该请求引发异常，因为它不完整。 API 指定异常以及如何使“完整”请求没有异常。
AuthorizationProvider 的计划也不错。将定义 API 以阐明哪些请求执行了 AuthorizationProvider。
“我努力应对可能发生的事情的爆炸......这个清单可能会继续下去。”实际上，它没有。只需定义适合问题域的适当 API。
如果——由于某种原因——你害怕你不能定义一个 API，那么你也不能定义问题。
“但是……”例如，一些有颜色或 MSDS 的物品呢？确认对话呢？
颜色 -- 或其他详细信息，如 MSDS。首先，模型具有“需要颜色”设置。 UI 只是检查是否需要颜色对话框。这些只有有限的数量，所有这些都是您正在解决的问题的一部分，并且都可以列举出来。
确认稀有物品。同样，业务规则具有“需要确认”属性或方法。 UI 对此进行检查。这些只有有限的数量，所有这些都是您要解决的问题的一部分，并且都可以枚举。
您不会弹出新对话框。使用单独的 UI 和业务规则，您现在可以做两件事：
您没有添加大量代码。业务规则属性是几行代码。 UI检查是一行代码。
【讨论】：
某个地方的 UI 必须在某个时候将信息传递到业务层。无论您是否通过控制器等中间对象。业务层需要判断 PO 是否处于有效状态。如果不是，则返回说明问题所在的信息。这可以通过 PurchaseOrder.AddLineItem 方法调用或 PurchaseOrder.Validate 方法进行。我的偏好是从 PurchaseOrder.AddLineItem 方法返回验证信息，这样您就可以确定对象状态是无效的。
【讨论】：
演示者或控制器，取决于您是否使用 MVC 或 MVP 应该知道它，而不是域，域将断言（防御性编码）是所有需要的值，或者抛出异常，而不是请求它。
假设你不提供号码，你的模型抛出一个 AuthorizationNumberRequiredException，然后你的演示者从那里处理它。所以你的域没有与presenter耦合，它只是抛出错误，你的presenter必须知道如何处理它，但它不会重复逻辑。
【讨论】：
我做了更多阅读，发现 Martin Fowler 的 Notification Pattern 似乎旨在解决这个问题，以及 Jeremy Miller 的 Domain Centric Validation with the Notification Pattern。
这是 Fowler 对 Notification 的描述，它几乎准确地描述了我正在寻找的内容：
一个对象，它在域层中收集有关错误的信息和其他信息，并将其传达给表示。
【讨论】：