域层向用户界面“调用”的最佳方式是什么

“……”业务规则出于某种原因决定您需要授权代码。域层是如何进行通信的?”

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

1. 业务规则API简单地列出了业务规则需要的各种东西。用户界面负责发出完整的请求。这些东西不是动态的。这不像是商业规则的随机变化。这种东西有版本控制。

2. 例外情况很好。请求引发异常,因为它不完整。API指定了异常以及如何使“完整的”请求不包含异常。

3. 授权提供者也不是一个坏计划。API将被定义为澄清哪些请求行使了授权提供者的权限。

“我为可能发生的事情的爆发而奋斗……这个列表可以继续下去,“事实上,它没有。只需定义一个适合问题域的适当API。

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

“但是……”例如,一些有颜色或MSDS的物品呢?配置对话怎么样?

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

2. 稀有物品的确认。同样,业务规则具有“需要确认”属性或方法。用户界面检查这个。其中只有有限的一部分,所有这些都是您要解决的问题的一部分,所有这些都可以枚举。

您不会弹出新对话框。使用单独的用户界面和业务规则,您现在可以做两件事:

• 将信息添加到业务规则中;
• 让用户界面检查是否弹出对话框。

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

某个地方的UI必须在某个时刻将信息传递到业务层。不管您是否正在经历一个中间对象,比如控制器。业务层需要确定采购订单是否处于有效状态。如果没有,则返回说明问题所在的信息。这可以通过purchaseorder.addLineItem方法调用或purchaseorder.validate方法进行。我的首选项是从PurchaseOrder.AddLineItem方法返回验证信息,这样您就可以确定对象状态在那里无效。

演示者或控制器,取决于您是否知道MVC或MVP,而不是域,域将断言(防御编码)是所有需要的值都可以的,或者抛出一个异常,而不是请求它。

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

我读了更多的书,发现了 Notification Pattern 来自马丁·福勒,他似乎也打算解决这个问题 Domain Centric Validation with the Notification Pattern 杰里米·米勒。

这是福勒对通知的描述,它非常准确地描述了我正在寻找的内容:

一个对象,它收集有关域层中错误和其他信息的信息,并将其传递给表示。