背景

前段时间我整理了一篇开发设计文档的经验——《磨刀不误砍柴工，分享编写前端技术设计文档的二三经验》，做为对于2023年的收尾。

2024年1月，一年之初，正是立Flag的好时机。因为我今年有几本小说作品的计划，所以被分去了一部分写作精力。有限的精力，想要发挥更高的效率，还是需要一些策略，于是我想到了可以借鉴一下总结开发设计文档的经验。

每月中的某一周阅读一本技术图书，然后再用一周时间产出技术收获。这样读书写作两不误，我便不没有精力有限的顾虑了。

本月的阅读计划是：《架构简洁之道》。距离我上次阅读这本书，已经过去很长时间了，除了标题，内容已经记不太清了。

子曰：“温故而知新。”我十分期待带着点“历尽千帆”的心境去重新阅读这本书而获得的收获。

文章速读

本篇主要分享关于软件架构设计中以下工作内容：

• 了解软件架构设计中层次与策略及策略隔离；
• 了解软件架构设计中业务逻辑是什么以及意义。

软件架构设计的工作

策略与层次

所有的软件系统都是一组策略语句的集合，可以说计算机程序不过就是一组仔细描述如何将输入转化为输出的策略语句的集合。

层次

一条策略距离系统的输入/输出越远，它所属的层次就越高。而直接管理输入/输出的策略在系统中的层次是最低的。

在上图中，Translate 组件是这个系统中层次最高的组件，因为该组件距离系统输入/输出距离最远。

将这个加密程序写成下面这样，这就构成了一个不正确的架构，因为它让高层组件中的函数encrypt()依赖于低层组件中的函数readChar()与writeChar()。

function encrypt() {
	while (true) 
      writeChar(translate(readChar()));
}

策略隔离

软件架构设计的工作重点之一就是，将这些策略彼此分离，然后将它们按照变更的方式进行重新分组。其中变更原因、时间和层次相同的策略应该被分到同一个组件中。反之，变更原因、时间和层次不同的策略则应该分属于不同的组件。

通过将策略隔离，并让源码中的依赖方向都统一调整为指向高层策略，可以大幅度降低系统变更所带来的影响。

业务逻辑

业务逻辑是程序中那些真正用于赚钱或省钱的业务逻辑与过程。

业务实体

一项业务的关键部分通常被称为“关键业务逻辑”。“关键业务逻辑”通常会需要处理一些数据，这些数据被称为“关键业务数据”。

业务实体是计算机系统中的一种对象，这种对象中包含了一系列用于操作关键数据的业务逻辑。这些实体对象要么直接包含关键业务数据，要么可以很容易地访问这些数据。

如上图中，实体类Loan中包含了三个关键业务数据，以及三个代表了其关键业务逻辑的接口。

请求和响应模型

用例类所接收的输入应该是一个简单的请求性数据结构，而返回输出的应该是一个简单的响应性数据结构。

这些数据结构中不应该存在任何依赖关系。这种独立性非常关键，如果这里的请求和响应模型不是完全独立的，那么用到这些模型的用例就会依赖于这些模型所带来的各种依赖关系。

总结

我们来总结一下软件架构设计中以下工作内：

• 所有的软件系统都是一组策略语句的集合。通过将策略隔离，并让源码中的依赖方向都统一调整为指向高层策略，可以大幅度降低系统变更所带来的影响。
• 业务逻辑应该是系统中最独立、复用性最高的代码。在理想情况下，代表业务逻辑的代码应该是整个系统的核心，其他低层概念的实现应该以插件形式接入系统中。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。