谈谈架构经验-社区项目

前言

个人认为软件架构是一个由几个阶段构成的过程，输出高层面抽象性多角度的软件结构，可指导开发且可并行开发。

需要明确由需求决定架构，并且在过程中需要考虑业务背景 系统规模 技术趋势 开发团队现状等因素。

第一阶段

产出物：业务模型

经历需求评审后，对需求文档进行归纳总结与抽象，从参与者、操作对象维度进行抽象。

以近期的社区需求为例，我认为可以抽象出如下组件：

抽象出组件后，即可清晰梳理出组件之间的彼此关系：

第二阶段

产出物：逻辑架构

采取分层、分区、公共能力的措施，逐步输出逻辑架构。

• 最初的分层结构：

• 在分层结构基础上进行分层、分区：

• 结合具体功能场景与质量要求，进行分层、分区、提取公共能力：

第三阶段

产出物：时序图、流程图、数据模型、包结构

• 针对需求功能，绘制功能的时序图，明确需要哪些接口。
• 针对主要功能，缕清具体业务逻辑，绘制流程清晰的流程图。
• 基于需求功能、系统模型，考虑范式、反范式，输出数据模型。
  • 如下仅为表，在实际工作中，需要清晰列举所有列，以及表间关系。

输出数据模型是个非常具体化的过程。具体到使用关系型数据库还是nosql、需要哪些表、表之间关系、哪些字段等。

资源汇总表应具有以下特点：

• 包括所有类型的资源；
• 包括所有资源的共有属性；
  1. 如何判断是否为共有属性呢？不以字段名为依据，而是考虑字段表示一类含义的数据。例如文章首图、直播图片、想法首图等，可以都用first_img。
  2. 新增字段时要考虑第1点。
• 最好包含资源列表的所有资源，尽可能减少与具体资源表的关联。

资源汇总表和具体资源表的关系：

• 所有具体资源表的ID具有唯一性，不重复，使用同一个序列。
• 两个表具有相同的唯一标识，例如资源汇总表的一个想法记录ID为1000，则具体想法表相应数据的ID也是1000。一个优点，在资源汇总表中不需要使用具体资源ID+资源类型的条件组合作为唯一标识。

• 按照组件划分package，以下package适用于(包括但不限于)controller、facade、biz、service的包结构。

• 类层次，规定继承、实现关系。
  • 要求向外透出rpc时，从抽象业务模型维度去考虑与设计。如CommunityResourceFacade、CommunityUserFacade、CommunityUserOperationFacade。
  • 具体资源的service继承BaseCommunityResourceService。
  • 具体资源数据模型DO继承CommunityResource。
  • 具体资源对外数据模型DTO继承CommunityResourceDTO。

结语

先有需求，后有软件架构。软件架构是一个过程，从抽象到具体，输出具有指导意义的图示。