很多同学对技术派项目非常感兴趣，目前技术派教程已经更新了三十篇，今天就给大家讲讲技术派的架构设计，让你对该项目有一个整体的认识。
通常对于技术人员而言，在开启一个新的项目之前，做了前期的调研、立项之后，第一件事情并不是开始搭建工程、撸代码，一个整体的架构方案设计、评审都属于不可忽视的环节。
接下来我将尽量追溯还原技术派的整体架构，是如何从 0 到 1 进行敲定的。
不 BB，上目录：
1. 业务模块拆解
在查看本文之前，请确保已正确了解技术派的主营业务，覆盖的功能点，如有疑问，可以先体验一下技术派网站，访问地址：https://paicoding.com
在业务模块拆解这一过程中，除了业务属性维度之外，还有一个非常重要的属性是参与者角色。
1.1 角色拆解
作为一个社区系统，用户角色非常容易划分
- 读者：普通浏览文章的用户
- 作者：发布文章的用户
- 管理员：整个系统的超管
权限划分
那么这三个角色的权柄是怎么划分的呢？
从上图可以比较清晰的看出三个角色的划分
- 读者的所有功能，作者都拥有；但是作者存在部分读者用不了的功能（如文章编辑、修改、发布等）
- 管理员权限最大，覆盖读者、作者的所有功能点
差异性划分
接下来就需要抓重点，看一下上面三个角色的主要差异点在哪里
- 读者：主要是阅读文章
- 作者：发布文章，作为信息输出
- 管理员：整个系统的运营管理，如标签、分类管理，文章审核等；通常不怎么参与文章的阅读发布
基于以上分析，我们可以将技术派的用户分为
- 普通用户：作为社区的注册用户，围绕文章主体展开其覆盖的业务功能点
- 管理员：作为官方角色，主要负责整个社区的生态运营
1.2 业务拆解
整个社区系统，按找业务边界先进行一版本初始划分：
- 用户
- 文章
- 评论
- 专栏
- 消息通知
然后再针对上面的进行简单的细化拆分
再上面进行简单拆分之后，会发现几个关键点
- 专栏：实际上是一些文章的合集，因此专栏的很多功能点可以直接建立在文章的基础上
- 评论：评论实际上也是依托于文章的点评，因此它于文章的关联性很强
- 消息通知：
消息通知的触发点需要进一步确认，但是它本身又属于一个相对独立的业务板块，因此重点关注交互方式
什么样的需要通知？如何触发通知？
怎么通知给用户？
- 点赞、收藏、计数统计独立于核心业务功能之外的能力：
这种与业务相关，但是又可以抽离于业务之外独立存在，可以考虑建设通用的服务能力
社区的搜索、推荐，虽然不影响核心业务功能，但是否需要考虑？
社区运营
基于以上，我们进行业务模块拆分，先确定以下板块：
1.3 小结
通常，在业务拆解这里，希望达到的目的是让参与者，能知晓这个项目的整体情况，可以划分为多少业务域，明确业务模块的主营范畴，确定彼此的边界
在这一阶段，我们可以先对技术派的整体拆分，得出以下结论：
角色
- 普通用户：作为社区的注册用户，围绕文章主体展开其覆盖的业务功能点
- 管理员：作为官方角色，主要负责整个社区的生态运营
业务模块
- 业务侧：
文章
评论
专栏
用户
运营
- 基础功能测：
推荐
搜索
统计
消息通知
注意
- 一般来说，在整体设计阶段，每个业务模块，需明确的是主体业务功能，但并不需要拆解到一个一个具体的功能点，具体的功能点，放在详细设计中来体现
- 业务的拆解不是一蹴而就的，相反实际情况下，这个拆解经常会出现反复、变动的情况（如果有留心公司的组织结构调整的小伙伴，应该对这种情况不难理解）
2. 模块交互方案
接下来我们就需要将上面拆分的角儿和业务模块串联起来，看一下我们的整个系统是怎么玩的
2.1 整体交互设计
对于技术派的核心玩法，在于作者发布文章，读者阅读文章；整体交互相对清晰简单，实际上这一块是可以省略的；当然我这里也补上这个流程，主要以文章发布，到读者阅读文章，并点赞，作者获取通知这个流程，来串一下这个系统的整体交互流程
上面这个交互过程中，用户中心、文章、消息中心，可以是独立部署的服务，也可以是一个进程内的服务；但是从逻辑上，他们彼此是独立的；针对上面的操作流程，可以提炼下面几个点
- 用户首先通过用户中心登录系统
具体的登录方式可以是传统的用户名/密码，也可以是手机号验证码，亦或者是第三方OAuth2.0登录
登录之后，用户身份识别，可以是单机的cookie/session, 也可以是分布式会话，jwt等形式
- 文章发布
- 正向逻辑为作者发布文章
- 文章审核对于作者而言，则属于被动接收，即存在一个依赖关系，是自动审核，还是人工审核？人工审核怎么通知管理员来审核？
- 消息通知
- 读者给文章点赞之后，如何将点赞通知给作者？
- 这个点赞事件是同步触发给作者，还是异步？
2.2 登录交互方案
登录交互我们最终选择的方案是基于微信公众号来实现的，下面这个交互方案适用于个人公众号（如果是企业公众号，可以直接使用微信的相关的API）
2.3 消息通知方案
消息通知采用异步驱动，通过Event/Listener方式来实现解耦
3. 整体架构方案
上面的流程走完之后，接下来就是敲定整体的架构方案，通常一个好的架构方案一张图就完事了，注意越是前期在意的越不是细节
3.1 初版设计方案
下面这张图来自于技术派开始做之前绘制的，与最终的实现版稍有差异，无需在意细节
最初版的方案设计非常简陋，当然思路还是比较清晰的
从上面这个图，是否能抓住整个技术派的业务模块？是否能确定业务模块的定位（哪些偏业务属性，哪些偏技术属性）？是否能确定不同角色的侧重点？
能满足上面三个点，和其他人进行沟通时，不会产生歧义即可；当然上面这个图是缺少交互方案的，通常在业务架构图中，不太会整这个，有放在细节里进行铺开，也有放在详细设计中的
3.2 业务架构图
接下来看一下技术派最终定稿的整体业务架构图，如下：
再看一下前后台的业务拆分
最后再看一下技术派的技术架构图
4. 小结
这一篇不算是正规的技术架构方案说明书，更多的是将整个方案的落地过程给大家刨析了一遍，算是抛砖引玉，希望可以给大家今后写架构方案提供一点帮助。
现在总结的方案设计思路如下：
是不是还没看爽？
