架构的理解分为俩点
一是最高层次的系统分解
二是系统中不易改变的决定。
如果你发现某些决定并不像你想象的那么难以改变，那么它就不再和架构相关了。
企业应用的困惑
企业应用在某些方面比电信软件简单的多，多线程问题没有那么困难，无需关注硬件设备与软件的集成。
但是。在某些方面，企业应用又比电信软件复杂的多，企业应用一般涉及大量复杂的数据，
而且必须处理多种"不合逻辑“的业务规则。
企业应用的特点
1，一般涉及持久化数据。
2，一般都涉及大量的数据。
3，一般不涉及很多人同时访问数据。
4，涉及大量操作数据的用户界面。
5，企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。
企业应用的种类
设计中最具挑战性的是了解哪些候选的设计方法以及各种不同设计方法之间的优劣比较。进行候选的空间很大，
我们这里只考虑三方面。
第一：B2C网上零售。
其解决方案不但要考虑到资源利用的有效性，还要考虑到系统的可伸缩性，以便在用户规模增大时能够通过
增加硬件的办法加以解决。该系统的业务逻辑可以非常简单，获取订单，进行简单的价格计算和发货计算，
因此用户界面可以选择通用的WEB界面，以支持各种不同的浏览器。
第二：租约合同自动处理系统。
它的用户会非常少（不会超过1000个），但是他的业务逻辑缺比较复杂。处理提早解约和延迟付款这样的事件。
签订合同时验证各种数据，在UI上也很复杂，要求HTML界面能够提供丰富的功能和复杂的屏幕。
用户交互的复杂性还会带来事物行为的复杂性，一个复杂的数据库设计方案中可能会涉及200多个表和资产评估和
计价的软件包。
第三：开支跟踪系统
这样的系统用户很少，功能简单，涉及的表也比较少。这样带来的挑战有
一方面要快速开发，另一方面为他以后的发展考虑，也许后续他会集成到工资系统。
以上三个企业应用的例子都有难点，而且难点各不相同，当然也不能有一个适合这三个的通用架构。
选择架构时，必须很清楚地了解面临的问题。在理解的基础上来选择合适的设计。
关于性能的考虑
建议尽量减少远程调用。
配置上的最大变化会使得某些性能优化失效。
响应时间：系统完成一次外部请求处理所需的时间。
响应性：不同于请求处理，他是系统响应请求的速度有多快。
吞吐率：给定时间内能够处理多大的请求量。
模式
每个个模式描述了我们周围不断重复发生的问题以及该问题的核心解决方案。
模式的结构
模式就是为了设计者们之间提供的一组词汇，因此如果我告诉你WEB服务器是前端控制器和转换视图构建的。
而你又了解这些模式，那么你对我的WEB服务器构架就会非常清楚。