基于任务的UI(Task-Based UI)

捕捉意图的客户端交互前半段类似于基于DTO的交互，用户界面向服务器后端请求一个Customer的DTO对象，DTO返回到客户端时会在屏幕上显示，然后从这里开始就不一样了。

用户点按按钮后，客户端发送消息给服务器，告诉它做一些事情 (或者说命令它做事)，可能是“完成一个销售”，“审批采购订单”，“提交贷款申请”等等。

客户端只是发送一个消息到服务器，让服务器完成用户想完成的任务。 明确地告诉服务器，用户想这样做，服务器能够知道用户的意图。

这里banq再补充几句：传统的MVC模式中，通常我们在控制器中实现了Action，其实Action本身是对Command的反应，我们在服务器前端要做的是先接受客户端指令，然后再进入应对和执行。

消息类似信封，命令类似信封里的内容，服务器前端应该首先是一种消息接收者，通过Command Handler取出信封的内容。

也就是说，在新的架构中，消息模式取代了以前的MVC模式，如果服务器前端是REST呢？恐怕REST的四个命令(GET POST DELETE UPDATE)也不足够表达用户的意图吧？

[该贴被admin于2013-05-11 08:21修改过]

告诉服务器的方法是通过命令Command. 命令是一个简单对象，包括操作名称和需要执行操作的数据。命令可以看成是一个序列化的方法调用。

命令就是让服务器做事情。 命令语言学是很重要的，命令的定义可以设想如下场景：

一个断开连接的客户端发生了什么事情，如销售，这样可能要发送一个的“SaleOccurred”Command对象。 那么领域层是否可以对这个事情说NO? 如果服务器端可以拒绝这个事情就是一个命令，如果服务器不可以拒绝，那么它就是事件。

在英语语言中的有趣例子：““Purchase”购买”，这个词语可用于动词，也可以描述动词的结果：名词，在遭遇这种情况时，要确保的概念表示的是动词，而不是名词。 “购买”应包括购买什么，以及领域层期待的一些信息比如什么具体商品，而不是发送描述“购买”的DTO(这其实变成名词了)。

参考：
动词是个独裁者

简单，精辟

附图代码中的命令包括两个数据属性。 InventoryItem的ID和一个描述项目被停用原因的注释。 注释是和与命令相关联的属性，它是为了处理行为而所需的数据，这种为处理行为而准备的的命令数据点与传统DTO架构显著差异就是，这个对象整个数据是为了传输回服务器。

最重要的数据是ID相关的存货项目InventoryItem。它是对所有更新状态的命令是必须的，当然创建命令时就没有必要了。

开发人员应该普遍学习命令的定义，并非常迅速地开始使用命令来表达他们过去熟悉的CRUD词汇，如“改变地址ChangeAddress”，“创建用户CreateUser”，或“删除DeleteClass”等。 CRUD应该是默认避免的，这样整个团队能够集中关注用例是什么。

当电话公司将黄页发给搬迁到新地址时的客户时，是询问“ChangeAddress”? 还是更关注“更正地址Correcting an Address” 和 “重新定位客户Relocating the Customer”有什么区别?

是询问 “CreateUser”或者是 “RegisterUser”? “DeleteClass” or “DeregisterStudent”. 在这个过程中会培养对领域的洞察力，最好的方法是定义好用例，而命令是对应于用例的。(联系用例图 表达的正是某个操作角色做什么事情，这个做事情实际是一种命令)

值得注意的是，有时只有一部分数据的情况下，将只有“创建”，“编辑”，“更新”，“改变”或“删除”等CRUD操作。意识到这是支持所有的应用程序的简单信息。 但是不能落入陷阱，没有了解和这些CRUD相关用例中的意图(为什么要CRUD)。

命令作为一个概念并不难，但是对于许多开发者是不同的。 如果开发者把命令的定义看成代表很多工作要做，那么命令定义会成为一个瓶颈，这是不应该的。

基于任务的用户界面也被称为感应用户界面(响应式界面)，做好基于任务的界面关键是要搞清楚用户想如何使用软件，并引导他们。

传统的CRUD界面如下图，库存产品有多个状态，停用只是其中一个状态，而为停用设置的停用原因注释却一直要显示在界面上。

如果用户直接提交“停用”，他们提示必须输入注释，因为这是一个强制性输入字段，否则就会收到一个错误。

[该贴被banq于2013-05-10 11:43修改过]

基于任务的用户界面将采取不同的方法，它可能会显示一个列表清单项目，如上图所示。当用户选择停用是，会弹出一个新屏幕，询问他们为什么他们停用，如下图所示注释字段。

在这种情况下，如果用户的意图是明确的，那么导引他们到下一步处理过程，这就很容易建立一个能够代表用户意图的命令。

[该贴被banq于2013-05-10 11:48修改过]

总结：抓住两个行为设计：领域模型的行为和用户的行为。

通过消息包装(命令或事件)将这两者的行为联系上，不但可以得到稳定的可伸缩的软件架构(CQRS)，而且能够取得最佳的用户体验，一举两得。

Jdon分析法靠下面这张图将用户行为和领域模型行为合并在一起，如下图，需求用例中每一个命令都可以用这张图实现：

[该贴被banq于2013-05-10 12:16修改过]

最近，我一直在帮助我的一个开发人员纠正在“对象事件”设计过程中出现的问题，他“把很多对象操作场景”都简简单单看做了update，丢掉了关键的业务含义，可能造成逻辑设计上的缺陷。

基于任务的响应式UI实际是一种事件驱动编程模型，界面不断将发生的事件传递后端，需要后端有强大的事件驱动架构(Actor模型如Erlang/Scala)，事件驱动服务器有Nginx Node.js或Vert.x 以及Spring 的Reactor结合Websocket，每秒可以处理几百万个UI事件。

服务器后端性能大比拼

[该贴被banq于2013-05-14 11:06修改过]

看了这张图，感觉和我说的，业务模型统一描述：
http://www.jdon.com/44416
是相当一致的，呵呵。

呵呵，Jdon分析法也学习了你的思想，综合了大家的想法。非常感谢你分享了自己的思想。