团队游订单排导游项目概要设计
背景介绍
在进行项目概要设计之前，需要引入利益相关者的概念。软件系统所影响的人群并不限于使用它的人，软件系统并不仅仅是被使用，它会被构建、被测试，它需要被运维，它还可能需要修复，每种活动都涉及很多用户以外的人，我们把这些人统称为利益相关者。
项目概要设计不同于普通的迭代需求的设计。一般而言，项目需要从当前的系统架构现状，结合未来的架构规划，建设既能满足业务功能诉求，也能满足系统架构规划要求的系统，这才是一个比较理想的项目设计。
在项目设计过程中，会接触到业务人员、产品经理、研发人员、测试人员、项目管理人员等利益相关者，每个角色重点都会关心自身的关注点是否都能满足要求。
因此，架构师在进行项目概要设计的时候，需要从各个利益相关者的角度出发，并进行权衡，形成最终的架构设计描述文档指导项目。
团队游订单排导游项目主要是解决团队游的订单面临的排导问题，目前团队游的订单相对于普通的度假订单的差别在于团队游的订单出游人数较多，通常需要安排多个导游。但是当前的组团排导系统并不支持一个订单一团，并且一个团排多个导游的场景，因此需要基于现有的系统模型进行修改，以满足团队游的业务发展诉求。
领域模型
领域模型是将领域概念以可视化的方式抽象成一个或一套模型，通常以UML的类图、状态图呈现业务域的概念。
本次项目涉及的主要业务领域为“团队游”业务域。原来“产品线路+团期”下面的所有订单组成一个团，然后针对每一个团仅排一个导游。由于团队游的一个订单，出游人数经常超过100人，导致一个订单下面的一个团太大，需要分配多个导游，鉴于目前的模型不支持，需要优化调整模型，实现一个订单一团，一个团支持多个导游的模式，以满足团队游业务的发展。
模型调整之后，同样需要针对导游报账，支持到订单维度。我们以组件图的形式表达产品、订单、团、导游的关联关系，如下图所示：
调整前模型
调整后模型（变化见红色字体）
针对一单一团多导游模型，在导游预支报账的时候，能够根据订单查询，并根据团进行预支报账。充分利用现有的预支报账模型，完成团队游订单的出游费用管控。
情境视图
情境视图主要是描述系统与其环境之间的关系、依赖和交互，通过情境视图帮助利益相关者理解其责任，以及如何与其他组织进行协作，完成整个系统的运转。
涉及利益相关者：团队游的产品客服人员、团队游的业务管理人员、研发人员。
客服通过订单系统的入口，进入到自组团系统完成组团和排导游的工作，导游和团的数据流转到导管系统，供导游知悉游客信息。
导游的预支报账相关功能，由客服发起，导管系统支持到订单维度。
具体自组团导游管理相关的交互场景图，如下：
功能视图
功能视图描述了系统运行时的功能元素，以及它们的职责、接口和主要交互关系。
涉及利益相关者：团队游业务客服，团队游业务总监，项目研发人员、测试人员
通过对团队游订单的分析，结合情境视图中涉及的各个系统分析，需要调整的功能如下：
自组团系统
1、调整现有的“产品+团期”组团的模型，支持一订单一团的模型
2、调整现有的一团一导游的模型，支持一团多导游的模型
导游管理系统
1、导管系统预支报账支持到订单维度，能够根据订单查出对应的团信息
2、导游预支报账OA审批中，增加支持订单的录入，审核流程中可见
3、导游任务单优化，能够清晰的呈现订单、导游、团信息
针对项目涉及的功能设计时需关注以下内容：
1、自组团和导游管理系统的设计，需要尽可能的通用，设计灵活，不限于团队游订单系统。
2、功能设计研发的时候，业务以及系统上保持松耦合。
3、自组团、导管、订单各自功能业务域内聚，禁止循环依赖。
信息视图
信息视图主要描述系统存储、操作、管理和分发信息的方式。在项目中，主要呈现出对数据库的调整相关的操作，以及对数据量的评估，对数据库的存储进行技术选型。
涉及利益相关者：数据库管理员，研发人员，测试人员，运维人员
项目设计，基于现有的自组团模型，对现有的系统能力进行扩展，以满足团队游业务的要求。本次项目主要是针对现有的系统能力进行拓展，支持一订单一团多导游的场景，不涉及新增数据库的变更操作，因此数据模型保持原有的模型。
关于数据一致性
关于订单、导游、组团的数据均存放在Mysql数据库中，数据为实时获取，为实时从数据库中获取。因此能够保证数据的一致性和实时性。
从安全视角而言
目前数据库的数据并未进行加密处理，数据访问可通过数据库查询系统进行权限管控，数据服务依赖公司底层的RPC协议，仅内网可访问。本次不涉及敏感数据，因此信息存储不做加密处理。
从国际化视角而言
关于导游的个人数据不涉及国际化信息，关于预支报账的费用以人民币作为单位，暂不支持多币种，因此暂不涉及国际化相关内容。
并发视图
并发视图是用于描述系统的并发结构，并把功能元素映射到并发单元上，以清晰的识别出系统能够并发执行的部分，以及如何协调和控制完成系统的运作。该视图主要面向研发测试人员关注并发带来的问题以及解决方法。
利益相关者：项目研发人员、测试人员、系统运维人员
关注点
系统之间的交互通信以服务的形式，服务为无状态的服务；当系统由于并发引起的性能瓶颈，需要分析出瓶颈所在点，可以通过横向伸缩，拓展服务实例数量以提升性能。
本次项目内容涉及的系统主要是客服系统，并且订单、自组团、导管都有对应的专属客服操作，是会存在客服同时操作一个订单的并发场景。多个客服同时操作但是这种概率非常小，在系统中，不进行特殊考虑。发生并发操作场景，涉及到的数据变更，客服重新调整即可满足。因此在系统设计研发过程中，基于研发成本以及性能考虑，忽略并发带来的影响。
开发视图
开发视图是需要描述项目开发过程中的架构，指导研发人员在研发过程中遵从的架构原则。
利益相关者：项目研发人员、测试人员
关注点
本项目涉及的系统模块有自组团系统、导游管理系统、团队游订单系统。
本项目涉及到的自组团系统的模型调整，导游管理系统支持到订单维度，需要具备通用处理能力，不能仅限于团队游业务才能使用，设计尽可能的遵循通用的原则。
测试人员需提前熟悉相应的业务流程，熟悉团队游业务。
技术栈：
项目涉及的后端系统采用的均为SpringMVC框架，后端研发人员均熟悉该框架，能够结合现有的代码和业务进行分析研发；项目涉及的前端系统，主要为JavaScript，JQuery，H5相关知识，前端研发人员对订单系统、前端框架较为熟悉，因此能够把控前端风险。
部署视图
部署视图是描述将要部署的环境，以及系统与其中元素的依赖关系。
利益相关者：研发人员、测试人员、系统运维人员
本项目主要为团队游系统的业务拓展，无新增系统或者新增依赖，系统均部署在公司的Docker云平台。每一个系统均为集群部署，应用部署可伸缩。
部署依赖关系如下图：
环境部署的时候，被依赖的系统先部署。如自组团订单依赖关系图中，要求导管系统先部署，然后自组团系统部署，再到订单系统的部署顺序。
问题与缺陷
由于自组团与导管系统的运行时，二者职责不一样，导管系统会依赖自组团的数据服务，因此如果二者上线有先后顺序，中间间隙有可能会导致导管部分功能不可用。
解决方法
鉴于晚上导管APP用户活跃程度比较小，并且用户量不大，上线保持晚上上线，且自组团和导管系统时间间隔尽可能缩小。
运维视图
运维视图描述当系统运行在生产环境中，如何对其进行运维、管理和支持。
利益相关者：系统运维人员，运维工程师
关注点
1、本项目中，自组团和导管系统研发是对原有的功能进行升级，服务是向前兼容。
2、本次项目不涉及历史数据处理，因此不涉及数据的迁移。
3、监控层面，项目涉及的所有系统均接入Docker，能够实时监控到各个实例的运行状况，近实时告警；并且配置相应的JVM参数，增加宕机日志数据，有利于对日志进行分析；应用的日志均接入公司ELK日志平台，能够方便快捷的定位问题，修复问题。
4、项目上线前，自组团系统新接入Docker云平台，相关的服务需要重点关注对应的配置项都具备。
问题和缺陷
生产环境约束，目前上线方式并非采用分流逐步上线，而是全面发布上线的方式，因此需要在灰度预发布环境充分验证。
总结
在项目概要设计层面，以领域模型限定对应的业务域，在整体认知层面限定项目范围；以情境、功能、信息、并发、开发、部署、运维等七大视图，结合各个利益相关者的角色，站在各个视角去分析项目架构，尽可能在项目动工前期将存在的风险点识别出来，降低项目的整体风险。
1
END
1
往下看
扫扫二维码
加入粉丝群
途牛技术
**盼君留
**