什么是“智能 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 引用了一些优势，包括由在域建模方面相对不熟练的开发人员非常快速地初始交付简单应用程序，能够快速适应需求变化（只要需求的复杂性不增加）和可视化（低-/no-code 现代说法）工具可能非常有用。缺点包括与其他应用程序/服务集成的能力有限（因为集成是通过关系数据库进行的，这往往意味着集成需要对其接触的任何内容进行修改），业务规则的重用主要通过复制和粘贴发生，缺乏抽象使重构变得困难，并且有'

在 Evans 开发 DDD 的同时，敏捷在很大程度上出现了，很容易看出敏捷方法可能有利于智能 UI。但是请注意，只有当您可以合理地确定您知道需求将如何发展时，采用智能 UI 才是明智之举：如果您将设计决策视为部分关于积累，使用财务隐喻，调用未来需求的选项，您通过这样做重新编写看涨期权以获取溢价。如果您在仔细规划问题并确定需求不会朝着那个方向发展之后这样做，那么它可能类似于覆盖调用编写，但假设智能 UI 中的 YAGNI 更接近于“做空波动性” ”

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