我的业务逻辑异常是否会传播到我的控制器。

Question

处理由业务逻辑发起的异常的最佳实践是什么？例如，当用例数据验证失败时。

如果此异常传播到您的控制器，或者您在业务逻辑中处理它并向控制器返回更结构化的错误消息。

Answer 1

对此有不同的看法，所以我不认为你会得到一个“最佳实践”:)

我更倾向于允许我的域中的异常一直传播到集成层，这是rest-api场景中的控制器。域中的异常实际上是一个“异常”，因此回传一些结构化的数据可能并不是真正必要的。您可以选择使用某种约定或类似的方式向异常中添加一些代码。但是，如果您正在处理特定的异常，您可能会用一个特定的类来表示该异常，在这种情况下，您可以确切地知道发生了什么。唯一的问题是，当这个单独的例外列表开始变得笨拙时。

我倾向于使用通用的BusinessException。例如，对于想要本地化消息的情况，您可能需要让消息包含一些编码数据：

例如：

throw new BusinessException("[BC-Account-Invalid-E-Mail]: Invalid e-mail address specified.");

但这些将是实现细节。

Answer 2

有许多不同的实践，适用于不同的上下文。

在data validation的情况下，您的代码路径通常不会到达业务逻辑。

例如，假设我有一个web端点，它应该接受bids，其中每个bid消息都应该描述一个目标项目、一个bid价格和一个投标人等等。如果消息是错误的--有人将竞价的日期放在了预期的位置，或者目标商品id的格式错误，等等--那么通常的做法就是将业务逻辑完全排除在循环之外，就像您接收到带有无法识别的方法的HTTP请求消息一样。

FormData -> BidMessage | ParseError

是最基本的想法。

Either<BidMessage, ParseError> parse(FormData formData)
BidMessage parse(FormData formData) throws ParseError
void parse(FormData formData, BidMessageHandler onBid, ParseErrorHandler onError)

这个概念在几种不同的实现风格中工作。

，但这不会影响独立测试业务逻辑吗？

我不这样认为?测试平台可以像应用程序一样轻松地创建消息。

框架问题的一种方法是考虑来自存储库的并行情况。我们准备从持久化设备中取出字节，但不知何故，域模型需要理解这些字节--如果数据验证失败，会发生什么情况？

让存储库抽象存储关注点的一部分是，它允许业务逻辑完全脱离存储关注点。我们希望与输入的实现关注点保持同样的隔离。