Architecture 域层的最佳方式是什么；喊出；到用户界面

当您的域层或业务层（无论您想叫它什么）与UI完全分离时，它如何收集完成请求所需的信息

例如，假设UI发出向采购订单添加行的请求，并且业务规则确定您出于某种原因需要授权代码。域层如何将此信息传递回来？返回某种类型的响应代码，指示它需要授权？触发“需要授权”事件，看看是否有人响应？是否接受UI将实现的某种IAuthorizationProvider

---

所有这些似乎都没问题，但我很难找到企业可能需要的大量可能的东西。继续采购订单示例，如果某些项目需要颜色，该怎么办？有些人需要危险品申报id？有些人需要一个简单的“这是罕见的，你确定吗？”。这个名单可能会一直列下去。这感觉就像决定你需要的信息肯定属于域层。在一个非分层的应用程序中，你只需弹出一个对话框就可以得到你需要的东西。如何在适当分层的应用程序中执行此操作？

演示者或控制器，取决于您是否执行MVC或MVP应该知道的操作，而不是域，域将断言（防御性编码）为所有需要的值ok，或引发异常，而不是请求异常

---

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

某个地方的UI必须在某个点将信息传递到业务层。无论您是否正在通过中间对象（如控制器）。业务层需要确定采购订单是否处于有效状态。如果没有，则返回说明问题所在的信息。这可以通过PurchaseOrder.AddLineItem方法调用进行，也可以通过PurchaseOrder.Validate方法进行。我的首选方法是从PurchaseOrder.AddLineItem方法返回验证信息，这样您就可以确定对象状态是否无效。

“……业务规则确定您出于某种原因需要授权代码。域层如何将此反馈给您？”

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

业务规则API只是列出了业务规则需要的各种内容。用户界面负责发出完整的请求。这些东西不是动态的。业务规则并不是随机变化的。这类东西有版本控制

例外情况很有效。请求引发异常，因为它不完整。API指定了异常以及如何使“完整”请求不存在异常

授权提供商的计划也不错。API将被定义为澄清授权提供者执行了哪些请求

“我在为可能发生的事情的爆炸而挣扎……这个清单可能会一直列下去。”事实上，事实并非如此。只需定义适合问题域的适当API

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

“但是……”例如，一些有颜色或MSDS的物品呢。确认对话怎么样

颜色——或其他细节，如MSDS。首先，模型具有“需要颜色”设置。用户界面只是检查是否需要颜色对话框。其中只有有限数量，所有这些都是您要解决的问题的一部分，并且都可以枚举

对稀有事物的确认。同样，业务规则具有“需要确认”属性或方法。用户界面会对此进行检查。其中只有有限数量，所有这些都是您要解决的问题的一部分，并且都可以枚举

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

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

---

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

我读了更多的书，找到了Martin Fowler的代码，它似乎与Jeremy Miller的代码一样适合解决这个问题

这是Fowler对通知的描述，它非常准确地描述了我想要的：

一种对象，它将域层中的错误信息和其他信息收集在一起，并将其传递给演示文稿

---

但这些显然是商业规则。为什么它们会出现在与UI相关的presenter中。假设我在没有演示者的服务中使用这个域——我会复制服务中的规则吗？在某些情况下，通知是在异常情况下实现的。在其他情况下，它是一个带有属性名称的ErrorDictionary和一个带有单个错误消息的ErrorList（或List）。