出来工作近一年时间了，说实在的，以前在学校并没有真正意义上理解所谓的“架构设计”。给人的感觉好像是挺厉害的，但是比较抽象不好把握。在完成了几十个大大小小的项目需求之后算是有所感悟，究竟什么样的架构设计算是一个好的设计呢？个人觉得最让我们程序员关注的应该是以下几点：
1：架构的整体设计是否清晰。
能不能让人较快地把握整体框架的总体流程和设计思路。如果整个架构设计本身就没有理清楚思路那后面进行开发肯定是一团乱麻。
2：模块之间的协调与交互。
模块间是否有明确的边界定义和良好的接口设计。在不同职责的团队之间合作时，通常会有一些业务逻辑，既可以在“表示层”来完成，也可以“业务逻辑层”来做，这个时候往往会有些扯不清楚。虽然说不改前端代码（例如手机客户端）就无需用户进行升级操作，但是把类似“密码策略是否符合规则的判断”也放到后台业务逻辑中，总让人觉得变扭。
3：模块内的代码组织形式。
模块中的代码是否能够在，有新需求不断进入的情况下依然保持清晰的逻辑。这一点可能架构设计者能够把握的不多，主要是靠后面需求的执行者来维护，但是架构设计时的数据交互规范和接口调用规范是能起到很重要的作用的。某个业务的功能开发多了之后，对应的业务实现文件常常会有几千上万行的代码。有时候一个函数中有几十个判断逻辑，而且环环相扣，就像一个“八卦阵”，很容易让人迷失其中。在这样的代码基础上再去加入新的功能，在执行的时候的确是有点“颤颤巍巍”。
随着面向对象和设计模式的大行其道，从功能实现和代码组织的角度来看，传统的系统设计基本上都可以被划分为以下三层：
1.表示层，关注数据显示和用户交互。
2. 业务逻辑层，关注业务逻辑相关处理。
3. 数据访问层，关注数据的存储与访问。
这种“三层架构”的出现，解决了系统间调用复杂、职责不清的问题，同时有效降低了层与层之间的依赖关系，当之无愧成为软件架构的经典模式之一。
但是这种架构仅仅是从逻辑上区分了代码职责，理清了调用关系，并没有在物理上真正意义地将不同业务模块之间进行隔离。最终形成的是一个：功能集中、代码中心化、一个发布包、部署后运行在同一进程的应用程序，这也被称为“单块架构应用”。
对于单块架构的优缺点概括如下：
优点有：易于开发、测试（模式易于理解，并且有成熟的开发工具能够使用）；易于部署和水平伸缩（只需把对应的软件包复制到配置好运行环境的节点即可）。
不足有：维护成本增加（随着应用程序功能越来越多，团队越来越大，相应的沟通成本、管理成本、人员协调成本必然会显著增加）；持续交付周期长（代码逐渐复杂之后，构建和部署的时间也会相应增加）；新人培养周期渐长；技术选型成本高（初始的技术选型严重限制了将来采用不同语言或框架的能力。如果想尝试新的编程语言或框架，没有完备的功能测试集，很难平滑完成替换，而且系统规模越大，风险越高）；可扩展性差（不论是垂直扩展还是水平扩展，其代价都会比较高）；构建全功能团队难（这种开发模式在分工时往往以技能为单位，这将导致任何功能上的改变都可能需要跨团队的沟通和协调）。
总体来说，随着业务的不断扩大，需求功能的持续增加，单块架构已经很难满足业务快速变化的需要。一方面，代码的可维护性、扩展性、灵活性在降低；另一方面，系统的修改成本、构建以及维护成本在显著增加。可以说，单块架构应用的改造和重构已经势在必行。
