第 4 章 系统设计
4.1 总体设计思路
本系统总体设计主要分为以下三个部分：微信平台接入、多角色功能划分、后台数据管理。
微信平台接入：设计本系统如何与微信平台进行对接。
多角色功能划分：根据业务需求，划分出使用系统的多个角色，并给出个角色的功能划分及业务流程。
后台数据管理：系统后台对不同业务数据的管理功能。
4.1.1 微信平台接入方式设计
本系统基于微信平台运行，设计为挂接在预先申请并认证通过的微信公众账号内，系统申请并认证的账号中文名称叫汇居通，本系统的主要功能将被汇居通账号关注者使用；系统接入到微信平台的过程，是通过引导汇居通关注者注册到本系统来实现的，注册过程中，依据关注者的微信 ID,将注册者录入的姓名和手机号进行绑定，从而在本系统中产生用户身份，完成微信账号与系统用户身份的绑定。
基于微信的访问入口设计：同时使用关键字回复和和自定义菜单两种接入方式，后端用户：案场经理和置业顾问使用关键字回复入口；前端用户：购房者和推荐人使用自定义菜单入口。
4.1.2 系统角色设计
根据业务需求，本系手机端用户分设计为以下四类角色，以下为四类角色及其主要职责。
案场经理：负责创建置业顾问、分配客源，查看客源状态置业顾问：注册、登录、领取客源、客源交易状态维护购房者：注册、登录、退出、关注房源、修改房源状态、查看红包、佣金状态、推荐他人、提交意向楼盘推荐人：注册、登录、退出、查看佣金状态、推荐他人4.1.3 数据管理机制设计
后台业务数据管理，需要对以下业务数据进行后台管理，以支撑系统运转。
房源数据：房源基本信息添加、修改、图片上传、优惠信息更新案场经理：案场经理需要由系统后台维护，为每个楼盘创建并指派一名案场经理。
客源查询：在后台能够按楼盘查询各个案场的客源列表，总体掌握系统运行情况。
4.2 系统架构设计
4.2.1 微信平台接入架构设计
上图绘制出了用户、微信平台和本系统的交互过程。展示了用户与微信公共平台、汇居通服务器之间信息传递过程，从上图可以看出，微信公众平台作为关键的桥梁[6],连接了汇居通服务器与用户之间的沟通。
4.2.2 系统支撑软件架构设计
如上图所示，系统运行需要诸多软件支撑，用户端，使用浏览器访问系统功能页面，页面中的静态资源如 html 代码、css、js、图片等，由 Web 服务器软件 Nginx负责处理[4];动态请求如对数据的更新和查询等，由 Nginx 转交应用服务器 Tomcat进行处理，Tomcat 处理动态请求需要数据库系统 MySQL 的数据存储访问服务[1];Web 服务器、应用服务器和数据库系统，均需要安装部署在最底层的操作系统 Linux之上。
本系统的核心程序，部署在 Tomcat 应用服务器中，支撑本系统的软件平台是泽元的内容管理系统 ZCMS2.2 版本。Tomcat 采用 7.0 版本；操作系统采用CentOS6.3;数据库采用 MySQL5.6;Nginx 采用 1.6.0 版本。
4.3 系统数据库设计
通过对业务需求的研究分析，系统设计了如下业务表结构，表间关系图示如下。
系统表设计在综合考虑了数据库第三范式以及数据查询的便利性，设计了必要的冗余列，并对冗余列的更新进行了设计，目标是兼顾查询便利性、尽量减少多级跨表查询。
以下为系统核心业务表的详细设计说明，按子章节展示如下。
4.3.1 在售楼盘表
在售楼盘表用于存储通过本系统销售的楼盘信息，主要包括楼盘名、楼盘简介、佣金、返现、主力户型、面积、所属区域等信息，属于本系统的基础实体信息表。
4.3.2 案场经理表
案场经理表，用于存储案场经理基本信息，包括其姓名、电话、所属楼盘 ID,微信昵称、微信 ID、邀请码、可分配置业顾问数量等，属于系统基础的实体表。
4.3.3 置业顾问表
置业顾问表，用于存储置业顾问的基本信息，包括其姓名、电话、所属案场经理、楼盘，微信昵称、微信 ID、邀请码、上次登录时间等，属于系统基础的实体表。
4.3.4 购房者表
购房者表，用于存储购房者的基本信息，包括其姓名、电话、身份证，微信昵称、微信 ID、佣金信息、上次登录时间等，属于系统基础的实体表。
4.3.5 客源表
客源表，用于存储从购房者转换的客源基本信息，包括其姓名、电话、来源（来自推荐人或购房者主动关注）等，属于系统基础的实体表。
4.3.6 推荐人表
推荐人表，用于存储推荐人的基本信息，包括其姓名、电话、身份证，微信昵称、微信 ID、佣金信息、上次登录时间等，属于系统基础的实体表。
4.3.7 推荐人-客源关系表
推荐人-客源关系表，用于存储推荐人的与客源的对应关系，属于多对多的关系，本表同时存储推荐人与客源、购房者与客源的两类关系，购房者关注楼盘，相当于购房者推荐了自己，在本表中存储了佣金发放时间、支付时间和佣金状态，属于系统基础的关系表。
4.3.8 客源-在售楼盘关系表
客源-楼盘关系表，用于存储客源与楼盘的对应关系，业务上，需要支持客源同时关注或购买多个在售楼盘，因此，这个关系也是多对多，本表属于系统的基础关系表。
4.3.9 置业顾问-推荐人关系表
置业顾问-推荐人关系表，用于存储置业顾问与推荐人的对应关系，业务上，需要支持一个推荐人与多个置业顾问产生业务联系，因此这个关系也是多对多的关系，本表属于系统的基础关系表。
4.3.10 客源状态变化表
客源状态变化表，用于存储客源在各个楼盘的交易进展情况，需要存储的字段包括：客户ID、置业顾问ID、购房者ID,交易状态、状态描述楼盘ID等，本表属于系统的核心关系表。
4.3.11 意向楼盘表
意向楼盘表用于存储用户提交的意向楼盘，这些楼盘未出现在当前在售楼盘列表中，属于需要通过本系统采集的基础信息，需要存储的字段包括：楼盘名、楼盘 ID,购房者 ID;楼盘基础数据来自与网站系统的楼盘基础信息，用户提交意向楼盘界面提供了基于楼盘名的模糊搜索，然后存储了内置的楼盘 ID.本表属于系统的基础信息表。
