背景

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

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

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

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

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

文章速读

本篇主要分享关于软件架构设计的边界的知识内容：

• 了解软件架构设计如何划分边界；
• 了解软件架构设计中常见的边界形式。
• 了解软件架构设计中三种实现边界的形式。

软件架构设计边界

划分边界

边界的作用

边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。

在项目初期划分这些边界的目的是方便我们尽量将一些决策延后进行，并且确保未来这些决策不会对系统的核心业务逻辑产生干扰。其中有一些边界是在项目初期——甚至在编写代码之前——就已经划分好，而其他的边界则是后来才划分的。

如何划分边界

边界线应该画在那些不相关的事情中间。GUI与业务逻辑无关，所以两者之间应该有一条边界线。

BusinessRules 是通过 DatabaseInterface 来加载和保存数据的。而 DatabaseAccess 则负责实现该接口，以及其与 Database 的交互。

所以边界应该穿过继承关系，在 DatabaseInterface 之下，如下图：

插件式架构

插件式架构是一种软件设计模式，它允许软件方便的增加插件，从而构建一个可扩展、可维护的系统架构。

插件式架构的好处在于它可以降低系统架构的复杂度，使框架更加易于扩展和维护。此外，它还能支持不同插件之间的松耦合，从而提高了灵活性和扩展性。

边界形式

一个系统的架构是由一系列软件组件以及它们之间的边界共同定义的。而这些边界有着多种不同的存在形式。

• 跨边界调用：跨边界调用指的是边界线一侧的函数调用另一侧的函数，并同时传递数据的行为。
• 单体结构：单体结构是最简单、最常见的架构边界，通常并没有一个固定的物理形式，它们只是对同一个进程、同一个地址空间内的函数和数据进行了某种划分。
• 动态链接库：它是系统架构最常见的物理边界形式。这种类型的组件在部署时不需要重新编译，因为它们都是以二进制形式或其他等价的可部署形式交付的。
• 本地进程：它是系统架构更明显的物理边界形式。本地进程一般是由命令行启动或其他等价的系统调用产生的。本地进程往往运行于单个处理器或多核系统的同一组处理器上，但它们拥有各自不同的地址空间。
• 服务：它是系统架构中最强的边界形式。一个服务就是一个进程，它们通常由命令行环境或其他等价的系统调用来产生。

不完全边界

介绍三种不完全地实现架构边界的简单方法。

• 省掉最后一步：构建不完全边界的一种方式就是在将系统分割成一系列可以独立编译、独立部署的组件之后，再把它们构建成一个组件。
• 单向边界：它是一个临时占位的，将来可被替换成完整架构边界的更简单的结构。
• 门户模式：它是一个更简单的架构边界设计。在这种模式下，不需要依赖反转的工作。

总结

我们来总结一下软件架构设计划的边界的主要内容：

• 在软件架构中画边界线。第一步是将系统分割成组件。组件包括两个部分：系统的核心业务逻辑组件和与核心业务逻辑无关但负责提供必要功能的插件。第二步是通过修改源代码，让这些非核心组件依赖于系统的核心业务逻辑组件。
• 大部分系统都会同时采用多种边界划分策略。一个系统中通常会同时包含高通信量、低延迟的本地架构边界和低通信量、高延迟的服务边界。
• 架构师的职责之一就是预判未来哪里有可能会需要设置架构边界，并决定应该以完全形式还是不完全形式来实现它们。

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