学习《架构整洁之道》

30 数据库只是实现细节

从系统架构道的角度来看，数据库并不重要——它只是一个实现细节，在系统架构中并不占据重要角色。

数据库只是一款软件，是用来存取数据的工具。从系统架构的角度来看，工具通常是无关紧要的——因为这只是一个底层的实现细节，一个达成目标的手段。一个优秀的架构师是不会让实现细节污染整个系统架构的。

但不管关系型数据库的设计有多么有智慧、多么精巧、多么符合数学原理，它仍然也只是一种技术。换句话说，它终究只是一种实现细节。

数据库流行是因为硬盘访问数据慢导致的。

为了应对硬盘访问速度带来的限制，必须使用索引、缓存以及查询优化器等技术。同时，我们还需要一种数据的标准展现格式，以便让索引、缓存及查询优化器来使用。概括来说，我们需要的就是某种数据访问与管理系统。现在流行的两种系统为：文件系统与关系型数据库系统（RDBMS）。

• 文件系统是基于文档格式的，它提供的是一种便于存储整个文档的方式。
• 数据库系统则主要关注的是内容，它提供的是一种便于进行内容检索的存储方式。其最擅长的就是根据某些共同属性而检索一系列记录。

这两种系统都是为了优化磁盘存储而设计的，人们需要根据它们的特点来将数据组织成最便于访问的模式。每个系统都有一套索引和安排数据的方式。同时，每种系统最终都会将数据缓存在内存中，方便快速操作。

从系统架构的视角来看，真的不应该关心数据在旋转的磁盘表面上以什么样格式存在。实际上，软件架构应该对磁盘本身的存在完全不关心。

性能难道不是系统架构的一个考量标准吗？当然是——但当问题设计数据存储时，这方便的操作通常是被封装起来，隔离业务逻辑之外的。也就是说，我们确实需要从数据存储中快速地存取数据，但这终究只是一个底层实现问题。我们完全可以在数据访问这一较低的层面上解决这个问题，而不需要让它与系统架构相关联。

本章小结

数据的组织结构，数据的模型，都是系统架构中的重要部分，但是从磁盘上存储/读取数据的机制和手段却没那么重要。关系型数据库强制我们将数据存储成表格并且以 SQL 访问，主要是为了后者。总而言之，数据本身很重要，但数据库系统仅仅是一个实现细节。

31 Web 是实现细节

为了应对多种 UI 风格，我们应该做的就是将业务规则与 UI 解耦。

GUI 只是一种实现细节。而 Web 则是 GUI 的一种，所以也是一个实现细节。作为一名软件架构师，我们需要将这类细节与核心业务逻辑隔离开来。

其实我们可以这样考虑这个问题：Web只是一种 I/O 设备。

我们其实可以从UI和应用程序之间的另一条边界出发来进行抽象化。因为业务逻辑可以被视为是一组用例的集合。而每个用例都是以用户的身份来执行某种操作的，所以它们都可以从输入数据、处理过程以及输出数据这个流程来描述。

也就是说，在UI和应用程序之间的某一点上，输入数据会被认为达到了一个完整状态，然后用例就被允许进入执行阶段了。在用例执行完之后，其生成的返回数据又继续在 UI 与应用程序之间传递。

这样一来，完整的输入数据，以及完整的输出数据就可以被标准化为数据结构，并提供给执行用例的进程了。通过这种方式，我们就可以认为用例都是以设备无关的方式在操作 IO 设备。

## 32 应用程序框架是实现细节 框架并不等同于系统架构。

请不要嫁给框架！！！

我们可以使用框架——但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它们进入内圈。

如果框架要求我们根据它们的基类来创建派生类，请不要这么做。我们可以创造一些代理类，同时把这些代理类当作业务逻辑的插件来管理。

另外，不要让框架污染我们的核心代码，应该依据依赖关系原则，将它们当作核心代码的插件来管理。

以 Spring 为例，它作为一个依赖注入框架是不错的，也许我们会需要使用 Spring 来自动连接应用程序中的各种依赖关系。这不要紧，但是千万别在业务对象里面到处写 @autowired 注解。业务对象应该对 Sping 完全不知情才对。

反之，我们也可以利用 Spring 将依赖关系注入到 Main 组件中，毕竟 Main 组件作为系统架构中最底层、依赖最多的组件，它依赖 Sping 并不是问题。

本章小结

总而言之。当我们面临框架选择时，尽量不要草率地做出决定。在全身心投入之前，应该首先看看是否可以部分地采用以增加了解。另外，请尽可能长时间地将框架留在架构边界之外，越久越好。