干净的架构：我应该把我的例外放在哪里？

Question

首先，我向您介绍上下文。我正在用 C# 和 ASP.NET Core 编写一个 api，我正在尝试遵循简洁的架构。

总之：我不知道把我的例外放在哪里。我写了一个小场景来解释我的逻辑。

1. 假设我在一个具体的网关中抛出一个 DuplicatePersonException。
2. 这个异常将被我的用例（交互器）作为一个简单的异常捕获。我不认为用例必须知道真正的异常。
3. 当我发现错误时，我将在我的 OutputBoundary（演示者）中调用一个方法。
4. 最后，此演示者将格式化答案并根据 DuplicatePersonException 准备足够的 ActionResult。

如果我尊重“内部依赖”，我必须将我的 DuplicatePersonException 放在我的用例层中。为什么不在领域层？因为它不必知道这种异常。更重要的是，我不知道我是否必须创建一个抽象的自定义异常并在网关层和展示器层中扩展它：这让我有点困惑。

在晴朗的，这种解决方案不健全的对我好，但我无法解释为什么。把我的例外放在这一层感觉不对。

总之，如果您有任何建议或解决方案，我将非常乐意接受！

非常感谢你帮助我！

Answer 1

（我认为这篇经典文章中的图像说明了问题中的各个层次，如果“实体”和“域”是同一件事：https ://blog.cleancoder.com/uncle-bob/2012/08/13/the -clean-architecture.html）

首先，抛出调用代码无法捕获的异常是没有意义的。那你不妨扔掉Exception。

这与返回实体的想法相同。如果您的实体是在网关中定义的，您的用例将无法接收它们。

假设您的网关PersonEntity从数据库或外部 API 获取 a。在干净的架构中，PersonEntity应该在网关中定义，并映射到PersonEntity域中的另一个，然后映射到PersonDto演示文稿中的另一个。

这些实体是完全独立的；他们都没有延伸对方。我认为这会违背目的。

这是我的建议：

在用例层中定义并捕获。 DuplicatePersonException

在您的域层中定义另一个更通用的异常（可能InvalidDataException），并从您的用例中抛出该异常（或在方法调用中转发）。