第6部分 实现细节
第30章 数据库只是实现细节
如果就数据库与整个系统架构的关系打个比方，它们之间就好比是门把手和整个房屋架构的关系。
一个优秀的架构师是不会让实现细节污染整个系统架构的。
关系型数据库
数据按行组织成表结构本身并没有什么系统架构意义上的重要性。应用程序的用例不应该知道，也不应该关心这么低层次的实现细节，需要了解数据表结构的代码应该被局限在系统架构的最外圈、最低层的工具函数中。
很多数据访问框架允许将数据行和数据表以对象的形式在系统内部传递。这么做在系统架构上来说是完全错误的，这会导致程序的用例、业务逻辑、甚至UI与数据的关系模型相互绑定在一起。
为什么数据库系统如此流行
我们需要的就是某种数据访问与管理系统。过去几十年内，业界逐渐发展出了两种截然不同的系统：文件系统与关系型数据库系统（RDBMS）。
数据库终究只是在硬盘与内存之间相互传输数据的一种手段而已
但性能怎么办呢
我们确实需要从数据存储中快速地存取数据，但这终究只是一个底层实现问题。我们完全可以在数据访问这一较低的层面上解决这个问题，而不需要让它与系统架构相关联。
直到今天我们也能看到这种市场宣传，譬如“企业级”“面向服务的架构”这样的措辞大部分都是市场宣传噱头，而跟实际的工程质量无关。
本章小结
数据的组织结构，数据的模型，都是系统架构中的重要部分，但是从磁盘上存储/读取数据的机制和手段却没那么重要。数据本身很重要，但数据库系统仅仅是一个实现细节。
第31章 Web是实现细节
一开始我们以为计算资源应该集中在服务器集群中，浏览器应该保持简单。但随后我们又开始在浏览器中引入Applets。再后来我们又改了主意，发明了Web2.0，用Ajax和JavaScript将很多计算过程挪回浏览器中。我们先是非常兴奋地将整个应用程序挪到浏览器去执行，后来又非常开心地采用Node技术将那些JavaScript代码挪回服务器上执行。
GUI只是一个实现细节。而Web则是GUI的一种，所以也是一个实现细节。作为一名软件架构师，我们需要将这类细节与核心业务逻辑隔离开来。
第32章 应用程序框架是实现细节
框架作者想让我们与框架订终身——这相当于我们要对他们的框架做一个巨大而长期的承诺，而在任何情况下框架作者都不会对我们做出同样的承诺。这种婚姻是单向的。我们要承担所有的风险，而框架作者则没有任何风险。
解决方案
请不要嫁给框架！
我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它们进入内圈。
尽可能长时间地将框架留在架构边界之外，越久越好。
第34章 拾遗
Web控制器永远不应该直接访问数据层。
“C4软件架构模型”中认为，组件是在一个执行环境（应用程序）中的、一个干净、良好的接口背后的一系列相关功能的集合。C4模型以一种层级模型讨论软件系统的静态结构，其中的概念包括容器、组件、类。这个模型认为，系统由一个或者多个容器组成（例如Web应用、移动App、独立应用、数据库、文件系统），每个容器包含一个或多个组件，每个组件由一个或多个类组成。每个组件具体存在于哪个jar文件中则是另外一个维度的事情。
保持开放，但是一定要务实，同时要考虑到团队的大小、技术水平，以及对应的时间和预算限制。
