引言

0.1 架构

架构很难定义,唯一可以统一的有两点: 1.最高层次的系统分解;2.系统中不易改变的决定

Ralph Johnosn 认为,架构是一种主观上的东西,是专家级项目开发成员对系统设计的一些可共享的理解。这些理解可以表现为系统中主要的组成部分以及这些组成间的交互关系.它还包括一些决定,开发者们希望这些决定能及早做出,因为在开发者看来它们是难以改变的,架构的主观性也源于此

企业应用在某些方面比电信软件简单得多,比如多线程,无需关注硬件设备与软件的集成,但是某些方面比电信软件复杂得多,比如要处理大量复杂数据,还有很多不合逻辑的业务规则

大多数模式都还只适合某些特定的领域和分支

企业应用包含工资单、患者记录、发货跟踪、成本分析、信誉评估、保险、供应链、记账、客户服务以及外币交易等。

企业应用一般涉及持久化数据
企业应用一般涉及大量数据，一个中等规模的系统往往包含 1GB 以上的数据，庞大的数据量使对数据的管理成为系统的主要工作
企业应用一般涉及很多人同时访问数据。基于 web 的系统比起普通系统，使用人数指数级增长。事务管理工具可以处理这个问题，但是通常无法做到对应用开发者透明
企业应用涉及大量操作数据的用户界面屏幕。为了不同的使用目的，数据需要有很多表现形式。系统一般有很多批处理过程，专注于强调用户交互时的用例时，这些批处理过程很容易被忽视
企业应用很少独立存在，通常需要与散步在企业周围的其他企业应用集成，但是这些系统技术不同，协作机制也不同，企业经常希望用一种统一的通信技术来集成所有系统。这往往很难实现，比如说数据中概念的不一致（数据表设计、定义不同）。
业务逻辑往往有很多奇怪的条件，这些条件相互作用的方式也很怪异，成千上万的“一次性特殊情况”最终导致了复杂的业务“无逻辑”使得商业软件开发困难，必须尽量将这些业务逻辑组织成有效的方式，因为我们可以确定的是，这些“逻辑”一定会随着时间不断变化

最好将大型项目简化为小型项目

企业应用是多种多样的，不同的问题将导致不同的处理方法。我们要了解有哪些候选的设计方法以及各种不同设计方法之间的优劣比较。

考虑一个 B2C(Business to Customer)的网上零售商，需要能应付大量用户，因此，解决方案不但要考虑到资源利用的有效性，还有考虑系统的可伸缩性，以便在用户规模增大时能够通过增加硬件的办法加以解决。
考虑一个租约合同自动处理系统，这类系统用户数很少（短时间内不会超过 100 个），但是业务逻辑复杂（月供、提前解约、延迟付款···），规则的随意性大。而且 UI 设计上，因为逻辑复杂，所以要提高更丰富的功能和屏幕。交互的复杂性还会带来事务行为的复杂性：签订租约可能要 1~2 个小时，这期间用户要处于一个逻辑事务中。数据库设计方案中可能包含 200 多个表以及一些有关资产评估和计价的软件包
第三个例子是小型公司使用的开支跟踪系统。用户很少，逻辑简单。但是必须快速开发，另一方面又必须为以后可能的发展考虑（被集成到别的系统、添加新的功能···），初期要考虑设计，但是设计不得当又会添加额外的复杂度