<读书笔记>(模块层面)BMS-7:保持系统组件间的

"在软件开发过程中, 拥有从系统划分到组件封装的整个过程的能力至关重要."

原则: 平衡顶层组件的数量和相对大小.

做法: 在一个具有良好封装的系统(或子系统)内, 架构组件的数量应该控制在 6 到 12 �个之间, 一般来说 9 个是最为平衡的, 且让组件的大小尽量接近.(虽然牵强, 但可以尽量接近.)

好处: 这样做的好处是提升系统的可维护性, 且容易定位代码.

一个良好的软件系统架构应当包含适当数量的组件(components), 不多也不少. 在任何实际复杂产品的制造过程中也是这样的, 包含尽量合理数量的组件(同一维度下, 比如汽车在某一个维度就可以看成是车上, 车轮, 车架, 发动机, 变速箱等大型的组件组合而成的, 而到了细分, 发动机(子系统)里面又有许多小的组件.). 且它们的相对大小都是在同一个数量级的, 即大小比较接近.

我们将一个平衡的系统架构定义为拥有好的组件平衡.

而组件不平衡的例子就是一个系统中�存在一个超大组件将所有的逻辑都包含了, 然后存在非常多小型组件, 相对这个大组件的体积小到可以忽略.

再来总结一下, 组件平衡的系统中:

• 包含不多也不少的顶层组件数量, 一般在 6 到 12 个之间. 最优值在 9 个.
• 顶层组件的相对大小都是在一个数量级上, 且大小尽量接近.

动机

上面描述了什么样的架构才��称得上是组件平衡, 下面就来看看为什么组件平衡如此重要.

一句话说: 组件平衡的系统在维护的时候更加�容易, 也更容易定位代码, 更容易分析代码, 更容易对代码进行独立修改, 更容易进行合作维护.

如何应用

实践中的原则主要有两点:

• 理想情况下的顶层组件数量应该维持在 6 到 12 个之间, 最优的数量是 9 个.
• 组件的代码数量在同一个数量级, 且尽可能接近(主要看代码行数).

实际过程中不要死死地就盯着� 9 个这样的数值, 而应该关注清晰的组件任务或功能划分, 如果拥有了清晰的组件任务划分, 系统的组件数量和组件代码量都应该能达到组件平衡的要求.

下面就来讲讲具体的做法.

1 在一个正确的概念层级上将系统进行组件划分

通常情况下, 软件系统都是按顶层的功能领域(即�描述系统为用户提供的功能)来划分的, 而另外一些系统是按技术领域来划分的.

比如系统按功能领域分, 可分为: 数据获取, 入账管理, 报告, 系统管理等等. 每一个�组件的源码里都会用到比如数据库或前端等的功能调用.

按功能领域来划分在软件设计时非常有用, 而对于开发过程中的开发者而言, 通过这样的功能划分, 可以对系统顶层有非常明确的概念性认识.

又比如系统按技术领域来划分, 可以分为: 前端, 后端, 接口, 日志等等.

如何选择合理的系统功能划分方式, 这个任务是架构设计的时候完成的, 这个设计可以是架构师完成, 也可以是多个人共同参与.

2 理清系统功能领域并保证实现时的一致性

确定了系统组件划分方式后, 就需要按组件划分对系统进行一致地实现. 这里的一致指的是实现时对于系统组件功能划分的一致性, 不能一个组件是按前端, 而另外一个组件又是按数据获取来实现.