企业对外提供服务，通常借助于软件应用。比如交易零售系统，用来提供购买商品的服务，这里就涉及到交易数据，这些数据会被用户“反复”的产生、查看，而且随着服务时间增长，应用本身也会面临困难
- 业务逻辑。业务本身是有一定的逻辑性的，但会经常出现特殊的业务场景，导致出现"无逻辑"的复杂业务
- 数据增长。应用本身会产生大量的数据，他们每天会被大量的用户同时操作、同时访问，需要确保最终数据的表现是符合预期的
- 三方依赖。企业应用本身会与其它企业应用集成，与不同的企业应用集成面临不同的风格
- 开发效率。一方面必须快速的开发出来，一方面又要考虑后续发展的可能性，如果不做后续发展的考虑，灵活性不够，会带来额外的复杂性，影响系统发展，但这额外的考虑又会可能“挑战”开发进度，影响效率
- 应用性能。响应时间、吞吐率、负载、容量、可伸缩性
架构模式基本概念
架构
架构是一种主观上的东西，是对系统设计的一些可共享的“主观理解”，可共享性表现在系统中主要的组成部分以及他们之间的交互关系。对架构的定义能够统一的内容有两点:
- 最高层次的系统分解
- 系统中不易更改的决定
模式
模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心，这样能够一次又一次的使用该方案而不用做重复的劳动
使用分层分解复杂软件系统的优劣
层次模型致力于将企业应用组织成不同的层次，并协调各层次之间的关系
- 优势：一层可以作为一个有机整体，无需理解其它层次；一层是可以替换的，只要保证层次的服务一样；只要构建好了一层就能够为很多上层同时提供服务；分层之后有利于标准化；层次之间的依赖性降低
- 劣势：层次不能封装所有的东西，比如数据库加了一个字段，会造成级联修改；过多的层次会影响性能
三层架构的系统
- 表现层：处理用户与软件的交互，比如HTML界面
- 领域层：处理业务逻辑，根据表现层得到的数据，进行验证、计算以及确定使用哪个数据源进行存储
- 数据源层：与数据库、消息系统、事务管理器等交互，大多数就是持久化数据
这里的层次是逻辑上的，不一定是物理上的隔离，所有层可以在1个服务器上，也可以是多个物理机
组织领域逻辑的方式
有三种组织形式 事务脚本、领域模型、表模块。
他们之间并不互相排斥，可以在事务脚本中处理部分领域逻辑，同时使用表模块或者领域模型来处理剩下的部分
事务脚本
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。简单的来说就是从表示层获得输入、进行校验和计算处理、将数据存储到数据库中以及调用其它系统的操作等等
- 优点：使用过程模型简单易懂；能够与简单数据源层很好的协作；事务边界清晰
- 缺点：多个事务要做相同的事情或者类似的动作时，拆分提取公共的子例程棘手，容易导致程序结构杂乱无章
领域模型
合并了行为和数据的领域的对象模型（每个类都有行为和数据，类之间交互来完成任务）。简单来说就是每个对象都承担一部分相关逻辑
- 优点：能够利用现成的技术来组织日趋复杂的领域逻辑（前期准备好了，后期好使用）
- 缺点：使用复杂、数据源层复杂
表模块
处理某一数据库表或视图中所有行的业务逻辑的实例，它处于领域模型和事务脚本的中间地带
