基线架构：
（来自http://xuliangyong.iteye.com/blog/321945）
架构基线的定义
架构是最终系统的一个早期版本，也称为架构基线。架构基线是整个系统的子集，我们称之为骨架系统（skinny system）。这个骨架系统包含了项目结束时的“丰满（full-fledged）”系统所具有的模型的一个版本。它包含了相同的子系统、组件和节点的骨架（skeleton），但是并非所有的“肌肉（musculature）”都已齐全。
架构基线的优点
架构基线能够为其他开发任务坚定坚实的基础，是开发组不再需要进行太多的开创性（高风险）工作----rup中架构基线里程碑的提出,其理论基础便源于此
在项目早期就解决所有高难度 高风险问题 永远是项目管理追求的目标
架构基线的缺点
只要缺少整体的结构规划 或者通用问题 高风险问题未被解决，后续工作就无法进行。
第五章从 仓库管理系统出发，介绍了怎么划分大泥球。层次怎么分解。再从每一个层所遇到的问题开始引入模式。最后以 一个总结结尾。
（来自http://blog.csdn.net/bxyz1203/article/details/7295748）
1、为了解决大泥球的问题，引入了 Layer 与 Domain Object 基本是一个垂直一个水平来拆分系统。Layer模式 主要给系统分层， 分为了，表现层、业务处理层、业务对象层、基础设施层、访问层。再在 业务对象层用了 Domain Object 抽象业务。
2、在业务处理层中，模块之间需要访问，我们采用了 Explicit Interface与Encapsulated Implementation模式。
3、接下来需要解决表现层与 业务处理层的访问关系。针对此点我们采用了Broker 模式。实现他的就是一个通信中间件。
4、表现层 需要分离用户的界面，采取了 MVC的模式。
5、为了解决全局对象分布的问题，采取了 Half-Object plus Protocol 模式.主要是把对象 分为几部分，独立部署，当client需要数据时可以从本地的Half object拿到对象。
6、支持并发的领域访问，采取了 Active Object模式。此在web 异步化中应用很广泛，具体就是 client 访问 service的时候，client 提交请求后可以忙活别的，等 service结束的时候可以采取相应的措施 让客户端知道。
7、为了解决可扩展的并发性。采取了 Leader/Followers 模式。具体就是 有一个 线程环，当请求需要响应时，从其中环的下一个节点拿出一个线程即可。此实现简单优雅。
8、对于领域对象与数据库关系的对应，此又有许多的模式，也是比较难解决的问题。一般是增加一层，叫数据访问层。此层使用 Database Access Layer等模式。
9、最后为了支持 模块的可动态卸载，可动态装配采取了资源管理的一个模式，Component Configurator模式
小结：
| 模式 | 应用 |
| Layer分层 | 根据不同抽象层次划分应用功能 |
| Domain Objcet 领域对象 | 在同一抽象层次内部划分和模块化应用功能 |
| Explicit Interface显式接口 | 为领域对象提供定义良好的访问接口 |
| Encapsulated Implementation封装实现 | 提供并封装领域对象的实现 |
| Broker 代理 | 定义通信中间件的基线架构 |
| Model-view-controller 模型-视图-控制器 | 将应用功能和表现及控制器区分开来 |
| Half-Object plus Protocol | 支持贯穿分布式边界的联盟式领域对象 |
| Active object | 为领域对象必须支持的请求调度提供并发性支持 |
| Leader/followers | 为需要大吞吐量的领域对象提供并发性支持 |
| database access Layer | 将应用功能从数据库细节中解脱出来 |
| Component Configuration | 由可重用组件为应用提供动态配置功能 |
参考文献：
1.http://xuliangyong.iteye.com/blog/321945
2. http://blog.csdn.net/bxyz1203/article/details/7295748