问题描述
在他的书中，实施领域驱动设计，Vaughn Vernon 说，
当存在渲染模型并驱动其行为执行的用户界面视图时，这些视图也在限界上下文中。然而，这并不意味着我们在用户界面中对域进行建模，导致域模型贫血。我们希望拒绝智能 UI 反模式 [Evans] 以及任何将属于模型的领域概念拖入系统其他区域的诱惑。
Eric Evans 在他的著作《领域驱动设计：解决软件核心的复杂性》（也称为“蓝皮书”）中强调了“智能 UI 反模式”的概念。
你能告诉我更多关于这种模式的细节吗？
解决方法
“智能 UI”只是一种反模式，因为它基本上与领域驱动设计不兼容。 Evans 特别指出，如果你不采用 UI 层、（薄）应用层、用于定义业务状态和应用业务规则的域层以及基础设施层的模式，“智能 UI”是非常有用的。可能是最好的选择，因为它优于半途而废的分层方法（例如，一种模糊应用程序、域和基础设施层中至少两个之间的界限的方法）。 Evans 的意图似乎是让您询问“智能 UI”是否可行，如果可行，那么您可能甚至不必费心进行 DDD，这通常会更加困难。
需要智能 UI 的情况是，如果应用程序以数据输入和显示为主，并且任何业务逻辑都足够简单，可以很容易地在 UI 中进行编码。在这种情况下，Evans 建议将域逻辑放在 UI 中（复数是因为每个功能都倾向于在自己的 UI 中），并使该 UI 或多或少直接与关系数据库交互。老式的服务器端渲染 PHP 方法或 20 年前典型的 VB 应用程序基本上是范例。
Evans 引用了一些优势，包括由在域建模方面相对不熟练的开发人员非常快速地初始交付简单应用程序，能够快速适应需求变化（只要需求的复杂性不增加），以及视觉（现代说法中的低代码/无代码）工具可能对此非常有用。缺点包括与其他应用程序/服务集成的能力有限（因为集成是通过关系数据库进行的，这往往意味着集成需要对其接触的任何内容进行修改），业务规则的重用主要通过复制和粘贴发生，缺乏抽象使重构变得困难，并且在交付这些需求的能力消失之前，功能性/非功能性需求的复杂程度是相当低的。
在 Evans 开发 DDD 的同时，敏捷在很大程度上出现了，很容易看出敏捷方法可能有利于智能 UI。但是请注意，只有当您可以合理地确定您知道需求将如何发展时，采用智能 UI 才是明智之举：如果您将设计决策视为部分关于积累，使用财务隐喻，调用未来需求的选项，您通过这样做重新编写看涨期权以获取溢价。如果您在仔细规划问题并确定需求不会朝着那个方向发展之后这样做，那么它可能类似于覆盖调用编写，但假设智能 UI 中的 YAGNI 更接近于“做空波动性” "（通常被描述为在街上的压路机前捡起小额硬币：你赚的钱很少，直到你被消灭）。
还值得注意的是，Evans 提出的智能 UI 交付速度更快的主要论点主要取决于实施（和管理）基础设施层的需要。自从 Evans 的书以来，人们可能会争辩说，支持 DDD 应用程序开发的框架（例如 Axon、Akka、Vlingo 等（仅命名 JVM 目标框架））的兴起在很大程度上消除了实现这些的难度，以及广泛的消息传递系统（Kafka、Kinesis、*MQ、Pulsar 等）、对象存储等，总体而言，DDD 方法值得付出额外努力的复杂程度已经降低。