有这些表现，才能算好的软件架构-《代码不朽》-《架构师书房》

特工行动之前需要对表，架构师开工之前需要干什么；好的软件“架构”，应该具备哪4个特征；什么是“组件”，好的“组件”应该如何表现；好组件与差组件的对比；多层架构，如何才是正确的依赖关系。

大家好，本期，我们分享《代码不朽》第7章的内容，也是本书的第6个原则，顶层组件之间应该做到松耦合（Couple Architecture Components Loosely）。

概念确认，就像特工行动前的对表行为

在好莱坞的动作大片中，特工在行动之前，往往需要对表，而这样的行为，对于架构师也很重要，只不过我们不是对表，而且在团队沟通之前，要进行概念确认。

计算机行业，特别是软件开发领域，看似很严肃、很严谨、很一丝不苟。其实待久了就会发现，很多概念，并没有严格的定义，有些即使有，也可能存在很多约定俗成的用法，也就是说的是一套，做的是另外一套。所以，在团队合作之时，需要提前确认，大家所说的概念是否一致，混乱比错误的危害更大。

好的“架构”应该这样

1，好的软件架构，能让你轻而易举的洞悉系统要做什么，是如何做的。

2，好的软件架构，能向你显示系统的高层架构，即系统的“骨架”。

3，好的软件架构，能方便你快速定位你寻找的源代码。

4，好的软件架构，能让你高效理解架构中各个组件是如何相互作用的（也就是组件之间的依赖关系）。

这里的“组件”是什么东东？

根据上下文以及文中的案例，我的理解是，这里的“组件”可以理解为一个或者多个相关的包（package），这个比较形象一些，至于什么是相关的包，可以从功能角度或者技术角度去看。

功能角度：对于一个常见的后台关系系统，用户登录相关的类，所在的包，就可以认为是一个组件。用户管理相关的类，所在包，可以看成是另外一个组件。这个不能一概而论。具体怎么划分，需要根据实际情况确定。

技术角度：对于一个常见的三层开发的web项目，业务逻辑层里面，可以根据不同的实体，划分出不同的组件。

对于如何划分组件，本书的下章，会有进一步的介绍。

好的“组件”应该这样

看图说话-好的组件 VS 差的组件

左侧：好的组件（Low component dependence） 特点如下：

1，很少的外部依赖（只有一个，灰色的那个）

2，代码职责专一

3，容易测试

右侧：差的组件（High component dependence），特点如下：

1，外部依赖多

2，代码职责多

3，难以测试

这几个图例大家要搞明白

浅绿色：internal（内部调用）

表示一个组件内部，模块之间的调用，这个是良性的，不会破坏组件的独立性。

深蓝色：Outgoing（传出调用）

表示一个组件中的某个模块，调用了另外一个组件中的一个模块提供的接口。一般是良性的，没有危害。

灰色：Incoming（传入调用）

和上面的“传出调用”是同时存在的，表示某个组件中的某个模块，提供了一个接口，供其他组件中的模块调用，也就是对外提供接口。

红色的：Throughput(透传代码)

看图说话-多层架构依赖关系的变质

上图是典型的，多层架构设计。

左侧是理想的依赖关系，它至少有两条规则：

1，上层依赖下层，反之，则不行。

2，上层只能依赖紧邻的下层，越层依赖则不行。

右侧是项目开发一段时间后，发生变质的依赖关系，从左到右，我们一一解释。

1，最左侧，User interface层，越过多个层，直接访问Database layer，违反上面第二条规则。

2，第二个依赖，Service layer越层依赖Data abstraction layer，同样违反上面第二条规则。

3，第三个依赖，User interface层，越层和Business logic layer 相互依赖，同时违反了上面两条规则。

实现组件松耦合的三个规范是什么；基于抽象工厂实现的云服务平台，是如何实现组件之间的松耦合。我们下期再聊。

极客架构师，专注架构师成长，我们下期见。