1、分层架构
在面向对象的程序中，用户界面（UI）、数据库和其他支持代码，经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为从短期的观点看，它是使系统运行起来的最容易的方式。
当与领域相关的代码和大量的其他代码混在一起时，就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变得不切实际，而且自动化测试也难以使用。如果在程序的每个行为中包括了所有的技术和逻辑，那么它必须很简单，否则会难以理解。
2、模型属于领域层
如果一个没有经验的开发团队，决定尝试试用一个使用了分层架构的模型驱动设计来开发一个简单的项目，那么该团队将面临艰难的学习曲线。团队成员必须要掌握复杂的新技术，并且经理学习对象姜末的艰苦过程（这是一个挑战，即时有这本书的帮助！）。管理基础结构和层的代价会使非常简单的任务的开发周期拖得更长。简单项目往往要求在短时间内完成而且期望的要求不高。因此，在这个团队完成被分配的任务之前，在他们还没有证明采用的方法会带来令人星峰的可能之前，这个项目早已被取消。
即时这个开发团队有充裕的时间来开发，如果没有专家的而帮助，团队成员可能会无法很好地掌握这种技术。最后，如果他们确实战胜了这些挑战，他们也只不过是开发了一个简单的系统，不会有人要求丰富的功能。
…
反模式——智能UI
把所有的业务逻辑交给用户界面处理。将整个应用程序分割成效的功能函数，并且把它们作为相互独立的用户界面来实现，同时把业务规则嵌入到这些界面中。用一个关系数据库作为数据的共享仓储。使用最自动化的UI结构，以及可利用的可视化编程工具。
优点：
- 对于简单的应用，生产力较高，开发时间较短。
- 缺少经验的开发人员可以经过较短的培训直接上手。
- 甚至在进行需求分析时所留下的缺陷，可以通过 把原型提供给用户来克服，并快速地在软件中作出修改来满足客户的要求。
- 应用可以相互分离，所以能够精确地计划递交小模块的进度表。对系统进行简单的扩展可能会很容易。
- 关系数据库工作可靠，并且提供数据级上的集成。
- 第4代语言（4GL）工具能很好的满足开发需要
- 当这个应用程序被递交后，维护程序员能够很快地重发开发他们没有结局的部分，因为改变所带来的影响只局限在每个特定的UI中。
缺点：
- 应用的集成比较困难，除非利用数据库
- 这里不会考虑重用以及业务问题的抽象。业务规则必须在每个使用它的操作中复制。
- 因为缺少抽象的提炼而限制了重构的选择，所以快速原型和迭代受到了天然的限制。
- 复杂性很快会让您迷失，所以增长路线只能严格顺着在原有应用上添加简单应用而已。要想获得具有丰富行为的应用并不容易。