什么是“智能 UI 反模式”？

Question

在他的书实施领域驱动设计中，Vaughn Vernon 指出，

当存在呈现模型并驱动其行为执行的用户界面视图时，这些视图也位于限界上下文中。但是，这并不意味着我们在用户界面中对域进行建模，从而导致域模型贫血。我们要拒绝 Smart UI Anti-Pattern [Evans] 以及将属于模型的领域概念拖入系统其他区域的任何诱惑。

Eric Evans 在他的著作“领域驱动设计：解决软件核心的复杂性”（也称为“蓝皮书”）中强调了“智能 UI 反模式”的概念。

您能否提供有关此模式的更多详细信息？

Answer 1

“智能 UI”只是一种反模式，它与领域驱动设计基本不兼容。 Evans 特别指出，如果您不采用具有 UI 层、（薄）应用层、用于定义业务状态和应用业务规则的域层以及基础设施层的模式，那么“智能 UI”非常可能是最佳选择，因为它优于半途而废的分层方法（例如，模糊应用程序、域和基础设施层中至少两个层之间界限的方法）。 Evans 的意图似乎是让您询问“智能 UI”是否可行，如果可行，那么您可能甚至不应该费心去做 DDD，这通常会更加困难。

需要智能 UI 的情况是，如果应用程序以数据输入和显示为主，并且任何业务逻辑都足够简单，可以很容易地在 UI 中进行编码。在这种情况下，Evans 建议将域逻辑放在 UI 中（复数，因为每个功能都倾向于放在自己的 UI 中），并让该 UI 或多或少直接与关系数据库交互。老式的服务器端渲染 PHP 方法或 20 年前的典型 VB 应用程序基本上是典型的。

Evans 列举了一些优势，包括由在域建模方面相对不熟练的开发人员可以非常快速地初始交付简单的应用程序，能够快速适应需求变化（只要需求的复杂性不增加），以及视觉（现代用语中的低代码/无代码）工具可能对此非常有用。缺点包括与其他应用程序/服务集成的能力有限（因为集成是通过关系数据库进行的，这往往意味着集成需要修改它所涉及的任何内容），业务规则的重用主要通过复制和粘贴发生，缺乏抽象使重构变得困难，并且在交付这些需求的能力消失之前，功能/非功能需求的复杂程度的上限相当低。

敏捷主要是在 Evans 开发 DDD 的同时出现的，很容易看出敏捷方法如何可能有利于智能 UI。但是请注意，只有在您能够合理地确定您知道需求将如何演变时，采用智能 UI 才是谨慎的做法：如果您将设计决策视为部分关于累积，使用财务隐喻，调用未来需求的选项，您重新编写看涨期权以通过这样做来收获溢价。如果您在仔细规划问题并确定需求不会朝那个方向移动之后这样做，那么它可能类似于 Cover-call 编写，但假设智能 UI 中的 YAGNI 更接近于“做空波动性” "（通常被描述为在压路机前的街上捡小价值硬币：你赚取微薄的利润，直到你被消灭）。

还值得注意的是，Evans 关于智能 UI 更快交付的主要论点很大程度上取决于实现（和管理）基础架构层的需要。自 Evans 的书以来，人们可能会争辩说，支持 DDD 应用程序开发的框架（例如 Axon、Akka、Vlingo 等（仅命名为 JVM 目标框架））的兴起在很大程度上消除了实现这些方面的困难。广泛使用的消息系统（Kafka、Kinesis、*MQ、Pulsar 等）、对象存储等，总体而言，DDD 方法值得付出额外努力的复杂程度已经下降。