架构经验：一种可行的架构方法论

目录

1. 前言

2. 详细了解需求内容

3. 抽象软件架构

4. 详细软件架构

5. 举例说明

6. 参考书籍与概要

6.1. 一线架构师实践指南

6.2. 软件架构理论与实践

6.3. 架构整洁之道

---

1. 前言

对软件架构的定义有很多，我个人认为软件架构是基于需求产出高层面可理解的软件结构，可以指导开发过程并发且快速进行，对后续运维和扩展多具有指导价值。

关于软件架构的书籍有很多，有的介绍其采取的实施步骤，如一线架构师实践指南，有的仅是介绍名词概念，例如软件架构简洁之道，不过这些名词正式业界多年的经验总结。

我阅读一线架构师实践指南时，有一种英雄所见略同的感觉，因为个人在工作中践行的架构方式与该书所讲内容有部分交集。

接下来，讲述本人一直践行的一种方法论。

按照从抽象到具体的顺序，将整个过程简单分为三个步骤：

1. 详细了解需求内容
2. 抽象软件架构
3. 详细软件架构

2. 详细了解需求内容

这个步骤中，需要参与需求评审，了解需求细节。

3. 抽象软件架构

首先需要抽象出业务模型，可以按照如下步骤进行：

• 列举需求内的参数者，包括人、物、有价值的名词。
• 对参与者进行分组，暂不考虑彼此关联性，而是按照类型粒度划分，同一类型内的参与者抽象为实体。

例子如下

从需求文档中列举出有价值的名词

• 理财师 用户 各种投资产品 订单 订单维度的佣金 当前月佣金 上一月佣金 组队 队长 成员 盟主 总监 团队佣金  当月销量 上月销量 达标队员

按照类型分类并抽象实体

• 用户类型： 系统用户实体（可标记为理财师 用户）
• 投资类型： 各种投资产品实体
• 订单类型： 订单
• 佣金类型： 订单维度佣金实体 当前月佣金实体（可标记为多种佣金类型） 月度佣金实体（可标记为多种佣金类型） 佣金系数规则实体
• 组队类型： 队伍实体 队长级别实体 
• 统计类型： 当月投资销量（用户或团队） 上月投资销量（用户或团队） 当月团队达标情况实体 月度团队达标情况实体

截至到此，输入需求，已产出抽象模块，甚至作为子系统。这些就可以作为抽象的业务模型。

然后输出系统模型，依据数据的上下游依赖，绘制模块间关系，不要产生循环依赖。

4. 详细软件架构

无论系统分为多个模块或多个子系统，都可以通过分层 分区 机制分离的步骤去绘制逻辑架构。<