什么时候异常被视为反模式？

Question

作为解决方案架构师，我一直在设计和派生软件架构模式。在这个过程中，我遇到了很多异常。由于技术环境不完整，它们大多被认为是例外，例如由于监管要求而缺少关键组件，导致我授予这些软件架构模式的例外。没有人喜欢例外，但它就是这样。就是这样。

我的问题 - 什么时候异常被视为反模式？还是有那个“灰色”区域？或者什么时候例外成为规则？像图案？

谢谢。

Nathan Aw（新加坡）

Answer 1

当您必须允许某些不适合您的架构的东西时，这意味着您不知道或未能预料到某些重要的事情，并且您的架构无法按照设计来适应它。

远见总是失败。你必须学会​​生活和处理它。是的，您需要尽可能了解您的客户及其需求，但这总是不完美的。除非您疏忽大意，否则远见失败并不表示您的流程存在任何问题，但每个问题仍然是了解客户的机会。

你错过的事情很重要，这更令人不安。当您设计的领域中有监管要求时，您不了解它们，并且它们限制了您可以构建的内容……这听起来像是您应该知道的事情。不过，我不知道您的具体业务，所以也许有一个原因，您的情况并非如此。

您的架构无法容纳您没有预料到的事情是真正的问题。您应该始终努力确保您不知道或无法预料的事情对整体架构无关紧要。这是你真正应该考虑的部分：“我在这个架构中做了什么假设，使它在这个维度上变得僵化？我怎么能在不假设知道这些我不知道的东西的情况下让我的架构工作?”

找出这些问题的答案，并在您的下一个项目中测试这些答案，将使您每年都变得更好。