领域驱动设计模型和Smark UI

最近在看ERIC Evans的《领域驱动设计》 ，里面提到了被称为反模式的Smart UI.觉得很有启发，摘要下来和大家分享。

在面向对象的应用程序中，分层架构似乎是一个广为接受的模式。这种将UI和领域对象隔离开来的做法，虽然有很多人尝试去做，但最后坚持下来的却极少。为什么在经过尝试后，分层架构在实践中被否定了呢?

SMART UI架构将领域知识和UI层混在一起。相对于分层架构而言，SMART UI架构简单得多。就是这个简单的SMART UI架构在时间中常常击败分层架构。

有很多软件采用了SMART UI这种架构，他们也应该继续采用这种架构。但是我们必须要明白，SMART UI架构和领域驱动之间的矛盾是不可调和的。他们就像是一条路的两个分支一样，最后通向两个完全不同的地方。

这里称SMART UI为反模式，是出于推广领域驱动开发的需要。下面我们就来看看到底SMART UI究竟是什么，它适用于什么类型的应用，不适用于什么类型的应用。搞清楚这一点非常重要，因为正如前面所说，一旦选择了SMART UI,基本上就无法再调整为领域驱动了。

如果软件功能比较简单，且以数据录入和显示为主，只有很少的业务规则。软件开发Team在面向对象建模方面经验较少。那么SMART UI的选择似乎就是必然的了。

首先，软件开发人员在面向对象建模方面经验不足。如果这时候采用分层架构的话，开发人员会遇到陡峭的学习曲线。面向对象建模以及相关的技术和工具都不是很容易就掌握的，但是分层架构却要求整个Team必须掌握。其结果必然是整个Team在纠结中一边学习这些新技术，新工具，一边开发软件功能。

分层架构系统中对基础架构和层次的维护会给开发带来额外的负担(这些都是和功能不直接相关的部分)。简单的项目通常要求快速开发，对软件的期望也不高。如果采用分层架构，做一个简单的功能都要费很多事情，而领域驱动开发的精彩之处又无法展示出来。这个项目恐怕还未完成就被取消了。

即使给开发小组更多的时间，如果没有专家的帮助，也很难学会和运用面向对象建模和领域驱动的知识和工具。即使他们克服了重重困难，学会了，掌握这些高级技术。最后发现，整个软件根本没有复杂到需要使用这些技术的程度。

有经验的团队不会遇到类似的问题。经验丰富的开发人员可以拉平学习曲线，同时压缩维护基础架构和层次所需要的时间。所以，领域驱动开发适用于雄心勃勃的大型项目，而且也要求开发团队经验和技能都能丰富。不是所有的项目都雄心勃勃，志向远大；也不是所有的开发人员都能经得起这些复杂技术的检验。

所以下面的场景就很合理了：

将所有业务规则都写在UI组件里。整个软件被切分为功能集，然后每个功能在一个UI组件中实现。采用关系数据库作为共享的存储仓库。使用最自动化的UI构建工具和可视化的编程工具。

这真是太邪恶了！我们一直都在说要把领域规则和UI隔离开来。是的，在领域驱动开发的环境下，我们称这种SMART UI模式为反模式。但是，这种模式也有它的优势，而且有很多场景本身非常适合使用SMART UI模式来开发。这也是为什么这个模式这么流行的一个因素。通过对SMART UI的分析我们可以更加清楚为什么我们要把领域规则和UI隔离开来。

SMART UI的优势：

1. 生产效率高，对简单的项目，立即可以看到效果；
2. 对程序员要求不高；
3. 原型和产品快速开发可以弥补需求分析方面的不足；
4. 模块按照功能来分割，在简单模块的交付上，可以规划得比较精确。如果要给软件添加新的简单功能也比较容易；
5. 关系数据库很好地提供了数据层面的集成；
6. 4GL工具很好用；
7. 在软件交接之后，如果实在无法理解某一模块的代码，维护人员可以直接重写。因为模块之间没有共享的东西，所以修改只会影响本模块。

SMART UI的缺点：

1. 除了通过数据库做数据集成外，很难做模块的集成。
2. 缺乏对行为和业务规则的抽象，同样的业务规则在每个模块中都被复制，而无法重用。
3. 快速原型和迭代开发有自然的极限。同时缺乏抽象导致重构受到限制。
4. 无法演化为复杂的软件，无法支持复杂的行为。

SMART UI如果使用得当，可以帮助开发团队避免使用其它模式带来的额外的负担。在选择开发模式的时候，有两个常见的错误：采用复杂的设计，然后又不能一直贯彻执行；或者采用复杂的设计，而实际项目根本就不需要。

使用SMART UI的一个后果就是，你永远被钉在这种模式上，除了重写整个程序外，你没有任何方法将它升级到其他架构。使用诸如Java之类的灵活的语言也不会带给你一个灵活的系统，反而会带来额外的负担。所以SMART UI最好采用4GL的语言和工具。

计划采用模型驱动开发或者领域驱动开发的团队尤其要注意到：无论多么有经验的团队，无论多么雄心勃勃的系统都是从简单功能开始迭代的。所以在一开始就要将模型驱动开发或者领域驱动开发所需要的分层架构，领域对象考虑进来(也许这时候你觉得他们是多余的)。否则你就会向SMART UI演化。并且永远被锁在那个架构里面。

讨论SMART UI主要是为了搞清楚在采用领域驱动开发的时候必须采用分层架构。Flower在《企业架构模式》(2002)中描述了TRANSACTION SCRIPT这个模式，用来将UI和应用程序隔离开来。但是该书没有提供TRANSACTION SCRIPT更加详细的对象模型。

采用领域驱动开发时对架构要求的底线是:如果该架构能够将领域相关的代码隔离出来，从而使得内聚的领域对象能够和系统的其它部分解耦，那么这个架构可能就是支持领域驱动开发的。

不同的场景，不同的要求下，其它各种软件架构都有其优势。但都会在软件的复杂性和灵活性上受到限制。所以未能将领域对象隔离必然带来灾难性的后果。如果你要开发一个复杂的系统，而且考虑采用模型驱动开发模式，那么请你一定要咬紧牙关，在专家的协助下，从一开始就避免SMART UI。