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

Question

在他的书“实现领域驱动的设计”中，沃恩·弗农说，

当有用户界面视图呈现模型并驱动其行为的执行时，这些视图也在有界的上下文中。然而，这并不意味着我们在用户界面中对域建模，导致域模型贫血。我们想要拒绝智能UI，反模式，埃文斯和任何诱惑，拖动领域的概念，属于模型到系统的其他领域。

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才是谨慎的:如果您将设计决策视为部分积累，使用财务隐喻，在未来需求上调用选项，则您正在编写调用选项以通过这样做来获取溢价。如果你是在仔细地描述问题并决定需求不会朝着这个方向移动之后才这么做的话，那么它很可能类似于覆盖电话写作，但假设智能用户界面中的YAGNI更接近“卖空波动性”(通常被描述为在蒸汽压路机前捡起小钱:你会赚点小利润，直到被消灭)。

还值得注意的是，Evans关于智能UI更快交付的主要论点主要取决于实现(和管理)基础设施层的需要。自从Evans的书以来，人们可以说，支持DDD应用程序开发的框架(例如Axon、Akka、Vlingo等)以及广泛的消息传递系统(Kafka、Kinesis、*MQ、Pulsar等)、对象存储等等，在很大程度上消除了实现DDD应用程序的困难，总体效果是DDD方法值得付出额外努力的复杂程度降低了。