应用控制器与UI机制解耦，及领域逻辑/应用逻辑边界的实用判断

应用控制器有两个核心职责：决定该执行哪段领域逻辑、决定该用哪个视图显示结果，为此通常维护两组引用——一组指向可执行的领域命令，一组指向视图（可以用命令模式、函数指针，或配合反射调用的字符串来实现这种”存一段待执行代码”的能力）。一个关键设计抉择是应用控制器该在多大程度上依赖UI机制——作者虽然见过直接耦合UI的应用控制器实现，但更倾向于让应用控制器和UI机制完全没有瓜葛：这样测试应用控制器时不需要依赖UI，也更容易支持同一套应用控制器逻辑服务多种外观。一个应用程序可以有多个应用控制器，常见做法是按用户界面的不同区域各配一个，只有简单应用才用单一的应用控制器；如果同时有Web前端、富客户端、PDA等多种表现形式，理论上可以让它们共用同一个应用控制器，但作者提醒这未必是好主意——不同UI形态往往需要不同的屏幕数据流才能做出真正可用的界面，为了省一点开发工作量而勉强复用同一套应用控制器，代价可能是牺牲各个UI形态本该有的可用性。应用控制器还常被组织成一台状态机：根据某个关键对象当前的状态，决定某个事件该触发哪个应答，这部分状态机的控制流本身适合用元数据来表达（可以直接用编程语言调用建立，也可以存进独立的配置文件）。至于该不该把领域逻辑塞进应用控制器，作者的态度是原则上反对，但也坦承领域逻辑和应用逻辑之间的边界经常很模糊——他举了保险业务的真实例子：仅仅因为申请者是吸烟者就要显示一个不同的问答屏幕，这到底算领域逻辑还是应用逻辑很难一概而论；作者给出的实用判断标准是看这类情况出现的频率——如果只是偶尔碰到，可以放心把它放进应用控制器里；但如果类似情况在多个不同地方反复出现，就该认真设计领域模型来把这两种逻辑恰当地分离开，而不是继续往应用控制器里堆。