产品架构严格意义上分为：信息架构、产品功能架构、业务架构。

信息架构：一般是指对用户接触到的信息进行规划（如：表单信息、界面原型，交互方式）

业务架构：一般是指如何开展业务的计划。绝大多数产品的业务架构是由公司BOSS拍板，轮不到产品经理决定。

产品功能架构：一般是指规划系统有那些功能模块功能，各个功能模块之间如何进行数据交互。好的产品功能架构，可以极大的减少团队开发成本。通常情况下产品功能架构直接称为产品架构。在产品经理的技能树上，只有点开了“产品功能架构”的产品经理，才算得上资深产品经理。除非是产品天才，绝大多数人都需要积累大量的经验和各种维度的知识才能做出合理的产品功能架构。

我们常常看到在很多团队中出现这样的情况——甲方提出一个新的业务需求，系统某一部分的功能就需要推翻重建。造成这个现象的原因实际上就是产品功能架构没有设计好，没有考虑到系统可扩展性。

这次我来分享下最近做的一个政府政务项目遇到的，“如何与多个三方系统同步用户信息的” 产品架构设计思路。

最近服务某市的政府项目（以下简称A项目）。这次的A项目包含了“建设+维护+运营”。和早几年甲方就是大产品，甲方要怎么做乙方就怎么开发，服务好甲方验收关键人，到点收“建设费维护费”的方式有很大的不同。这次必须保证A项目的运营效果，达到甲方要求的运营目标。

由于A项目的用户是全市公务员。第一次召开项目的需求研讨会时，甲方乌压压来了几十号人，各个业务口子的对接人都来了。结果产品组做需求调研走访各家单位就耗费了两个月。

甲方要求，A项目上线后，要求各级单位管理员在A项目上，管理各自单位的人员信息，便于市政府了解各级单位情况。全市公务员都要使用A项目。从而达到完成甲方的运营指标的目的。

听上去，蛮简单的吧？但是调研后发现，各个口子的单位（例如党组织部和公安机关）都有自己的IT外包团队负责自己的业务系统，各家IT团队的人员质量和系统质量也是参差不齐，各个口子的单位也是根据自身的业务情况设计的用户信息表。有的还有大量的垃圾冗余数据。各级单位的系统管理员，对同时在两个系统中管理用户信息的情况十分反感（提出要求在自己的业务系统中管理）。

为了在达成甲方的要求的同时减少项目实施阻力我设计了如下方案：

首选解决A项目的用户确权的问题？

根据以上的背景描述可以发现，存在某人在多个单位中的情况。例如张三是税务局职工，也是税务局党支部党员，还是税务局工会会员。税务局、党组织、工会组织这三个口子单位的业务系统中，张三的信息可能会存在差异。例如：由于张三的信息录入各家系统的时间不同，电话号码会有差异。以哪一个系统的用户信息为准，就成了一个难题。

经分析，所有单位的用户信息均含有姓名、电话、身份证。我将其定为 “基础用户信息”。A项目的用户登录和确权相关操作，只以基础用户信息为准。“单位用户信息” 用来各业务口子单位相关业务使用。

最终设计了，如下图所示的 “基础用户信息” 和 “单位用户信息” 的用户信息结构。

又因为，A项目属于标准的封闭服务系统。在项目上线运行的过程中，先有用户信息，再有用户登录操作。然而，系统先获得的用户信息是各级单位提供的，并且不同单位给出的用户信息也不相同。那么就需要考虑，如何判定登录A项目系统的用户，是哪一个单位的用户。传统的注册登录逻辑明显不再适用。

因此设计了如下图所示用户激活流程：

激活流程 时序简图

从上图可以看到，在用户激活这个流程中，共牵涉到几个功能模块。设计产品架构时就需要定义好这几个模块分别干什么事情。

在这个流程中，出现了一个“用户身份索引”的功能模块，这个模块的功能是为了“支撑”验证身份证是否存在于系统中。因为，系统需要对接全市各个业务口子单位的系统用户数据（以下简称三方系统）。为了在配合对方调整三方系统时，减少对A项目的影响，就需要为每个三方系统用户信息建立对应的单位用户信息表。

在新用户访问A项目进行用户激活操作时，如果采用直接到多个“单位用户信息表”中进行查询的话。那么每次有新的单位系统对接时，A项目都需要对用户激活流程进行升级。这样从成本考量明显不划算。

所以，设计了“用户身份索引功能”用来存储系统中的身份证号。如下图所示，三方系统同步过来的用户数据中的新增身份证号都存入“用户身份索引”。