从单体的插件化演化所引起的思考

的架构时，我们总会凭借原先的经验，并结合业务现状的需求，并根据未来的需求做出我们的设计。即：

• 过去的经验。
• 现在的需求。
• 未来的方向。

种种因素的影响之下，它注定了我们无法设计一个满足所有历史时期的系统。未来会变成现在，现在会变成过去。

Coco 架构设计：从过去到过去的未来

原先对于 Coca 的各种设计问题，以及 Golang 对于多平台的支持问题等多方面的因素。迫使 Inherd 开源小组在 Coco 在初始阶段，便考虑了为 Coco 设计插件系统。直到最近，我们实现了插件系统之后，发现了原来设计的分层架构已经不满足现今的需求。

虽然，我已经知道新的分层架构应该如何设计，但是我并不想朝那个方向过去。我走走弯路，再看看是否存在一些更有意思的设计。

原始形态：单体架构

在设计初期，我在 Coco 中引入了类似于 Clean Architecture 的分层架构设计(不包含 Cargo 模块)：

• app，对应于用例(usecases)。
• bin，对应于 controller。在 Rust 的构建系统中，bin 目录的会被构建出可执行文件
• infrastructure，对应于 基础设施，如调用 Git 的接口、访问文件系统等。
• domain，即业务实体、领域模式，包含了系统的业务设计。

在 domain 目录下，根据了我们的四大基本业务，进行了二次划分 ：

• cloc
• git
• framework
• architecture
• ……

尽管，我一直在说我采用的是类似于 Clean Architecture 的分层架构。但是实际上，并没有采用其中一些重要的设计，比如说通过依赖反转来控制流向的问题。从个人的角度来看：

1. 它带来一定的架构复杂度，需要不断地传递相关的架构知识，能否在开源项目中推广，有待商榷。
2. 后续可以通过重构来转换。我并非非常资深的架构专家，所以以学习为出发点更方便。

作为一个单体应用，这个分层结构凑合着：

1. 不算太复杂，还能让开发人员知道哪的代码往哪里放。
2. 可以按需演化为 Clean Architecture。
3. 模块可以进一步按业务拆分。

故事的开始还是蛮美好的。

复用形态之模块化

为了在多个不同的系统/应用之间(即 Coco 项目的代码提供给其它应用)复用代码 ，系统中产出一些独立的模块，如 psa、framework 等等。这也是一个

（编辑：桂林站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!