第五部分 软件架构
什么是软件架构？软件架构工作本质上是在回答一个关于“如何将系统切分成组件，并且处理好各组件之间的关系”的问题。一个优秀的架构师应该允许系统尽可能推迟与实现细节相关的决策。要设计一个好的软件架构，除了要使系统用例的正常运行，还要同时考虑系统的维护、开发以及部署等非需求因素。
那么为了尽可能地将一些与系统核心业务逻辑无关的决策延后，我们就必须划分好软件架构中的清晰边界。比如业务逻辑和数据库之间就应该有一条边界线，因为你是具体使用Oracle还是MySQL作为数据库，都不应该影响核心业务逻辑。同理，用户界面也与业务逻辑无关，所以这两者之间也应该有一条清晰的边界线。因为具体使用的是命令行界面还是使用网页等UI方式来呈现，本质上都与核心业务不是紧密相关的。在具体的架构实践当中，有一种叫做插件式架构的方式广为流传，其理念就是将核心业务逻辑和其他组件（作为外部插件）进行隔离开来。
一旦边界划分完毕之后我们就得进一步思考如何处理跨边界的调用，最简单的跨边界调用方式就是用低层客户端来直接调用高层服务函数，这在单体架构当中十分普遍。我们这里所说的高层和低层组件，其实是按照输入与输出之间的距离来进行定义的，通常来说它距离系统的输入或者输出越远，它所处的层次就越高，而能够直接管理输入输出的策略，在系统当中就是属于低层的。拿操作系统来举例，低层的组件就是那些管理磁盘的程序，而高层的组件就是依赖磁盘管理程序的文件管理系统。由于低层的组件通常来说比较容易频繁变更，而高层组件相对来说较为稳定，因此我们需要将低层组件隔离开来，并且将依赖关系都统一调整为指向高层策略。低层次组件要跨越边界到达高层组件，这个数据流是自下而上的。所以一旦我们需要使高层组件能够调用低层组件，就需要运用动态技术来反转依赖关系，比如使用动态链接库。对于我们常见的Main组件应该是整个系统中的一个底层组件，它处于整洁架构的最外圈，负责加载系统信息，然后将控制权转回到系统的高层组件。
要实现跨越边界的调用，除了直接的函数调用外，我们还可以引入线程，进程以及服务的方式。
我们在软件架构当中还经常提到的一个概念是业务逻辑，那么对于一个软件来说，其最核心的业务逻辑是什么呢？它本质上就是系统软件系统中那些能够真正产生商业价值的逻辑和过程，无论它是否是以计算机软件的方式进行实现的，它的作用和逻辑都应该是相同的。因此我们通常会将这些关键的业务逻辑出现成一个业务实体，并且作为高层组件，至于底层的具体实现则交由低层组件来完成。
在很多设计不佳的软件里，你经常会看到业务逻辑和数据库以及用户界面等逻辑相耦合，这样随着时间的推移，软件的可维护性和代码质量都很难得到保障。
一个系统的架构应该着重于对于系统，用例本身的设计，而应该尽量避免强依赖于系统所使用的框架。
跨越边界的数据，应该保持数据结构的简单，而且不应该违反依赖规则。
在系统架构的边界处，可以使用谦卑对象模式，这种模式可以很好的提高系统的可测试性。一个很好的例子就是对于GUI的实现，我们可以将其分为展示器和系统视图两个部分。其中视图部分属于谦卑对象，该对象只负责将数据填充到 GUI上。而另一部分是展示器对象，它负责从应用程序中接收数据，然后按照视图的要求将这些数据格式化。谦卑对象同样也可适用于数据库网关、数据映射器ORM等场景中。
我们通常会认为服务是解耦合的，但是一旦服务之间使用了共享数据，它们就会形成强耦合关系。按功能划分服务的架构方式，在跨系统功能变更时是比较脆弱的。那么对于这些横跨系统之间的变更，我们应该如何处理呢？如果运用面向对象方法，可以采用模板方法模式或策略模式来将原先服务化设计中的大部分逻辑包含在基类中，然后针对特定的逻辑可以抽离到一个单独的组件当中去。要是使用基于服务的方式，则可以用衍生类，为原有的服务添加新功能。
第六部分 实现细节。
这部分主要通过一个视频销售网站的案例分析，来阐述组建架构以及依赖关系管理等，处理的思考过程。
我们需要注意的是，无论是数据库、WEB UI还是应用程序框架，这些都是实现细节，不应该成为架构设计的阻碍。同时无论我们采用水平拆分的架构（按层拆分）还是采用垂直拆分的架构（按功能拆分），都需要将设计映射到对应的代码结构当中去。最好能够使用编译器来维护所选的系统架构设计风格，这些细节都很关键。