第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
繁荣的同人生态孕育出了庞大的周边二次创作市场。但时至今日，仍然没有任何针对该领域的专业化的订单管理系统。发起者借助社交平台进行众筹、参与人员从碎片化的聊天记录中获取需求信息、生产商基于私人社交网络寻找加工厂，全程处于极度分散的状态1。信息传达需要人为截图分享，筹集资金存在信任问题，追踪进程更是难上加难。如此原始的工作模式不仅效率奇低而且限制着优秀创作作品的商业性发展2。订单管理系统作为联系创意、生产和消费的重要纽带，其信息化程度决定着全产业链条的运转效率和服务质量。王伟平等人的研究表明订单管理和生产管理一体化是精确化管理的前提3。张东伟也在服装定制行业证明了智能化订单系统在优化生产过程中的积极作用。而唐洪美所研发的集中处理系统同样证实了流程整合的重要性。
1.1.2 研究意义
该系统的社会价值是为松散的同人周边创作者群体带来规范化、有迹可循的合作流程体系。它将分散式的交流、买卖行为固化为有组织的数据流，让订单环节对各参与方公开透明，极大地减少了由消息差导致的各种矛盾和损失。团长得到的是项目运营的专业平台，厂家得到的是稳定的客源以及明确的产品需求，而对于一般消费者来说则是获得了类似普通网购的消费权益保证。系统通过固化创意至交付的核心节点，为这一新生业态奠定了最为基本的商业模式，有利于更多资源注入从而促进产业从兴趣爱好走向半职业化乃至职业化。这套系统的设计思路对于其他一些存在多方协同作业、产品非常规化、预付定制等特征的小众市场，例如独立设计师、手工艺术品众筹等领域也有一定的借鉴意义。
1.2 国内外研究现状
1.2.1 国内现状
国内学者近年来对订单管理系统的相关研究也由原来的通用平台转向垂直细分市场，由单纯的记录型系统转变为嵌入业务流程的智能化协同平台。尤其是在定制化生产和服务业中，订单系统承担起了串联客户需求、生产过程以及整个供应链条的重责。国内学者的研究方向不仅仅局限于加快订单在公司内的流转速度，而致力于建立跨公司的信息节点，从而达到创意方、制作方与需求方即时互动的效果。这样的技术支持的发展方向也为解决繁琐、多方参与的订单合作环境提供了理论支持。
王伟平等在2024年开发的订单管理与生产控制一体化管控系统，主要是针对解决生产现场信息和订单信息实时同步问题，该系统的闭环反馈体系给本系统中的"订单发货管理"模块给予了直接借鉴，有利于促进顾客下单到工厂生产的全流程可视化效率提升4。张东伟在2024年对服装面料私人定制领域的智能化优化策略进行了探究，他在非标订单工艺匹配及排期方面加入算法予以智能调控，由此启发本系统在"工厂打样管理"、"打样对接"节点设计更加程序化的方式流程来响应同人周边多元化的定制要求5。唐洪美在2022年推出的订单集中处理管理系统V1.0，它的主要作用是实现分散订单来源的一体化收集处理，这种集中治理的理念直接服务于本系统"开团信息管理"、"参团购买管理"模块的功能实现，便于管理者集中审批、跟踪多个团长处发来的零碎订单6。
总的来看，目前国内外的研究对于促进订单系统与特定行业的深度耦合有较大的进展，但是对于支撑类似同人周边这样高度社群化、少量个性化定制以及多方灵活合作的特殊生态，其现有的系统支撑度还是不够完善，很多系统偏向于企业管理内部或者对标准化产品流程的支持，很少有可以类比从"设计打板-社群团购-订单履行"的整套社交化商业模式闭环。该系统就是基于此，在上述研究不足之处做出的功能拓展，以实现包括"工厂接单打板-多身份订单视角-即时聊天"为主要功能模块的设计，来搭建一个为设计师、制作者、消费者等组成的创意生产联合体提供服务的协作式订单管理系统。
1.2.2 国外现状
国际上针对订单管理方面的研究一直围绕着系统的柔性以及更好的决策支持和人机交互体验展开，近年来的研究更是结合了移动性、环境意识和灵活可变制造过程等新型的思想。研究人员努力让订单管理系统不仅是一个事务处理器，更成为一个可以进行及时决策、应对变化、改善体验的智能助手，他们的研究重点在于复杂的供应链环境下，信息系统怎样在可用性和自学习能力方面创造出业务价值从而构建一个多职能协作平台的不同方面。
Kunath and Winkler于2019年深度分析了信息系统可用性对于订单管理决策质量的影响。其研究成果指出了良好信息层次结构以及清晰的操作流程对于管理者效率的重要价值，这一定律成为了本系统设计"管理员审核"，"工厂打样审核"等一系列包含复杂状态判定操作页面的根本法则，以求减轻各类角色客户的单据关键节点的思考负担7。Masitoh and Astrianty于2024年完成了一套基于手机端的洗衣店订单管理系统，展示了轻量化、移动化的设计理念为传统服务业带来的便捷性和高效性的巨大提升，其研究为此系统日后适配移动端版本时，增强"用户参团购买"、"查看订单细节"的手机端使用体验提供了宝贵的应用实例8。Theresa-Franziska H et al.于2023年从订单管理角度切入研究流体制造系统，他们探索了系统如何响应不断变动的生产要素以及高度个性化的订单队列，面对生产条件不确定性的思路启发了本系统"工厂信息管理"的模块灵活呈现生产力参数与报价的设计，团长客户可以依据实时数据做出更加科学的打板生产选择9。
总的来说，国外研究对于增强系统交互便利性，便携移动性，环境灵活适应性等方面提供了先进的思路。但他们的研究都是建立在其本国商业环境基础上及配套设施上的，对于繁琐的审批手续、多方信用保障机制、以及强烈的群体交流等特性支持，与国内二次元周边行业实际情况并不完全契合。本系统吸取了他们关于用户体验和系统柔性的优秀设计理念之后并没有直接采用他们的方案，而是将其主要原则进行本地改良，例如将"决策支持"的概念实例化为结构化的"审核回复"，将"移动化"的追求落实为响应式的web架构以便尽快投入使用，最终目标是打造一个更适合国内创意群体合作流程的订单平台。
1.3 论文结构安排
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是一个用于创建一个用于简化基于Spring应用的初始设置和开发的后端框架。Spring Boot提供了默认设置以及启动器来大幅减少在传统Spring应用中需要编写的重复的XML配置。它能让你迅速地开发出一个独立的、生产级的基于Spring的应用程序，它可以被打包成一个单独的jar文件并且具备内嵌的servlet容器使得发布非常便利10。Spring Boot采用约定优于配置的理念来自动配置spring应用所需要的各种组件，并且可以方便地覆盖缺省值。
在此系统中，Spring Boot是后端服务的基础架构，承担搭建RESTful API来为全系统提供的业务逻辑服务。它结合了Spring MVC来处理Http请求消息，Spring Data JPA来方便地执行数据库的操作11。同时利用了它的自动配置功能迅速集成了事务管理、安全性等核心功能。其轻量级和快捷开发的特点，让开发者可以把大部分精力投入到复杂的同人周边订单管理业务逻辑的实现上去，而不必关注底层技术的集成，提高了开发的生产力以及系统的可维护程度。
2.2 Vue框架
Vue.js是一款构建用户界面的渐进式JavaScript前端框架，核心库专注于视图层，易于与第三方库或者已有的项目整合。Vue采取自底向上增量式设计，核心是一个以声明方式将数据渲染到DOM上的系统12。Vue.js拥有响应的数据绑定和组件式架构两大主要特点，响应系统可以保证数据与视图的一致性，当数据改变时视图相应更新，组件式把UI分成独立、可复用的代码块，每个组件都有自己的数据、状态和视图，大型的应用被分割成许多小型的应用更加明确容易维护。
在整个系统的前端部分都是由Vue.js来负责搭建全部的用户操作界面，在Vue组件的帮助下，该系统对后台管理端、工厂操作端、团长管理界面以及前端用户商城都进行了封装与复用。Vue Router管理前端路由，实现了单页面应用的无刷新页面切换体验；Vuex是一个状态管理库，用来集中管理应用中各个组件之间的公共的状态如用户的登陆状态，全局设置等等13。而Vue的响应式机制保证了诸如订单的状态、产品的库存量等数据库中的数据一旦发生变化就能立刻反应到用户界面上去，增强用户体验效果。
2.3 MySQL数据库技术
MySQL是一款常用的开源的关系型数据库管理系统。它基于结构化查询语言来访问和管理数据库，支持多线程、多用户并发操作，性能优良，可靠且易于使用。MySQL是基于客户端/服务器模式构建的，可用于大容量数据库处理并与主要编程语言很好地兼容。提供了诸如事务、外键、视图、存储过程等功能以满足大部分web应用对数据持久化的要求14。多种不同的存储引擎的选择也是mysql的一大特色，例如Innodb支持事务处理而MyISAM读取较快两种都可以由开发人员自由搭配选用。
本系统采用了MySQL作为主要的数据存储库。系统的全部数据如用户账号信息、开团信息、厂家信息、以及订单的相关信息、物流信息都保存在MySQL数据库之中15。使用关系型数据库的好处是可以借助其关系型功能，在设计好表与表之间外键约束的情况下，保证了数据存储的单一性和完整xing.比如参团购买记录与用户表、开团信息表的关系，使得订单能够顺利找到源头。而MySQL本身的稳定性及完善的生态系统又为其储存系统数据的安全性和可靠性护航。
2.4 前后端分离架构
前后端分离是当前一种新型的Web应用程序框架模式，它的基本理念是把前端用户界面层与后端业务逻辑及数据层相分离。前端负责展示和与用户的交互，它使用Ajax或者Fetch API等来请求调用后端暴露出来的RESTful API接口获得数据或是发送请求，而后端负责执行业务规则、验证数据并持久化保存，然后向客户端以Json等轻量级数据格式暴露出来作为数据服务16。它们各自独立开发、调试部署并通过API合约相互交互。
该系统使用的是前后端分离结构搭建。服务端使用Spring Boot提供了整套的、无状态的API接口，它们描述了系统所能做的全部业务逻辑。而前端的Vue.js应用程序则单独运行，它负责渲染视图、读取用户输入，并通过HTTP客户端请求服务端API。这样的结构有巨大的好处：前后两端可以选择更合适的技术栈；开发者能够并行开发提高速度17。前端可以带来更好的客户体验，能拥有更为复杂的SPA(单页面应用)式交互；而后端API也能被多个客户端重复使用，也为后续开发移动版应用提供了便利。另外架构间的明显分割使整个系统的可维护性与可拓展性都得到了提升。
第三章 系统需求分析
3.1 功能需求分析
UML用例图是用来表达系统功能性需求的一种可视化工具，用例图通过展现系统与外界参与者间的互动来描述系统具备的功能。用例图中的用例即代表了系统能够实现的一个具体的功能，而参与者就是与系统发生交互的不同类型用户或者是其它外部系统。在分析及设计过程中运用用例图可以确保一个系统的功能齐全准确，并使开发人员和客户达成共识。以直观的方式，UML用例图提供了系统功能和角色之间的关系。本论文将会基于角色模块来进行系统的需求分析。
3.1.1 管理员角色功能需求
管理员用于对系统的整体监控审核，保障基本秩序。主要的操作为对所有开团的信息在发布之前进行审核，浏览详情给出审核回复；管理所有用户的参团购买记录情况；管理订单发货之后的物流信息导出；审核工厂上传的基本资质材料信息；查看工厂申请打样记录以及打样的对接进展。管理员的功能是来保证整个平台内容符合规则、交易可信、流程顺利。
图3-1管理员用例图
工厂用户角色功能需求
厂merchandise用户负责生产端的响应及管理。它的职能以生产资源以及订单处理为核心，管理本厂的详细信息、产能；查询收到的打样申请单；审批团长发出的打样对接申请并上传样品；在周边商城发布自家经营的商品并维护商品信息。工厂用户从系统获取规范化生产任务，反馈生产进程。
图3-2工厂用户用例图
3.1.2 团长用户角色功能需求
团长用户是制作项目的发起方和管理者。团长用户的权限有查看和筛选厂家信息，在心仪的厂家处发出打样请求；发起和管理自己的开团项目；管理一个自营的周边商城；查看平台上其他周边商城并且购物；使用平台在线聊天工具与其他用户交流。团长用户通过系统集成创作、生产和销售流程。
图3-3团长用户用例图
3.1.3 用户角色功能需求
普通用户是周边产品的购买者。主要的功能为消费及互动，实现的功能有：使用线上聊天功能；查看和检索开团信息，查看详情并参团购买；管理自己参与团购购买的历史，在商家发货之后上传物流单据或者确认收货；阅读周边动态信息，对内容点zan、收藏、评论。客户在系统内部完成从接触商品到售后服务的全流程。
图3-4用户用例图
3.2 可行性分析
3.2.1 技术可行性
本系统基于Spring Boot、Vue.js、MySQL这样的稳定并且十分常见的技术栈来研发。Spring Boot用于后端服务的开发大大降低了难度，提供良好的项目结构体系以及依赖支持，可以迅速搭建出RESTful风格接口；Vue.js是渐进式的前端开发框架，适合用来研发复杂的企业级管理后台以及页面交互效果，庞大的生态体系中有许多优秀的UI库可以选择使用18。MySQL属于典型的关系型数据库管理系统，足以应付系统所需面对的用户、订单、商品等信息之间的关系管理以及事务操作，同时这几个技术栈都有非常活拨的开发者社区，相关学习资源众多，上手难度较低，并且针对分布式部署以及性能调优都有很成熟的解决方案，从而在技术支持方面为本系统的实现以及可靠运行提供了保证。
3.2.2 操作可行性
选择的技术栈有着成熟开发者工具与完整官方文档的支持，技术实现较为简易。Java，Spring Boot，Vue框架，MySQL数据库广泛用于系统的研发及运行之中，简化系统开发过程、前后端分离的设计能提升合作效率、B/S模式能减少系统发布时的繁杂程度。整项操作是可行的。
3.2.3 经济可行性
选用的技术框架都是开源的，减少了软件购买及授权的花费。浏览器/服务器结构减少了硬件方面的支出，降低了维护的开销。研发时间较短，产品能够快速上线运营，产生效益，确保成本和收益之间的平衡。
3.3 非功能需求分析
1.可用性需求
系统可得用性需要系统的架构要高可用，在面对用户高并发的情况下仍能保障系统的正常运转。系统应有快速恢复的能力，在发生错误后能够迅速完成自愈。为了提供更好的体验，系统要有高的响应速率，低延迟，能在极短时间内完成对用户请求的处理并将结果反馈给用户。系统要有负载均衡的能力，对多台服务器进行请求分发，避免因单点失效而导致整个系统崩溃的情况。
2.可靠性需求
系统可靠性需求即为系统在长期的运行中要稳定，不能频繁出现异常、中断的情况。要有完善的数据库备份及恢复机制，在机器硬件损坏或其他灾难出现时，能够使数据不被破坏并且尽可能迅速地恢复正常工作状态。系统的各服务与模块需要有良好的健壮性，当一部分模块失败时，可以无缝切换到备用服务上。
3.安全性需求
系统安全性需求用户的个人信息、交易记录等重要信息需严格保证其机密性。系统应对用户传输的信息进行加密处理以保证其在传输过程中的安全性而不至于被截获或被中途篡改。系统须进行访问控制，用户仅能访问属于自身权限范围内的资源，禁止未经授权的用户进入系统。系统要有身份鉴别机制，防范蓄意的用户假扮其他主体。为抵御外来侵犯，系统须具备如防火墙、入侵检测系统等安全保障机制用于防范来自网络层面的攻击。
3.4 本章小结
第四章 系统总体设计
4.1 系统总体架构设计
系统采取分层结构模式来组织代码逻辑，清晰地界定每一层的任务为达到高内聚低耦合的目标。客户端使用浏览器访问由Vue.js搭建的前端应用，前端应用利用HTTP请求调用后台提供的RESTful风格API。后台采用Spring Boot进行开发，采用标准的三层结构，其中web控制层用于处理请求、提取请求中的参数和反馈结果19。业务服务层包含系统的业务逻辑，它会组合多个数据访问来执行复杂的业务功能；数据访问层使用JPA访问Mysql存储的数据，用于保存或查询数据。这样前端和后台、后台内部又进行分层，使得整个系统有明确的分工界限，有利于分工合作、独立发布和后续管理。系统的架构图如下图4-1所示。
图4-1系统架构图
4.2 系统功能模块设计
本系统的功能是以同人周边订单管理为主线业务流程，针对四种重要用户类型定制化地开发其专属的功能模块。管理员角色是系统的管理者，具有开团信息发布，参团购买操作，订单发货管理，工厂信息管理，打样流程管理等重要权限。工厂用户角色立足于生产过程，它的功能包括工厂信息管理、申请打样、接收打样成品、自主上架产品。团长用户角色是项目的发起者，它可以查看和挑选工厂，管理自身发起的开团，经营自己的小铺，查看和购买商品，进行聊天。普通用户的角色是消费购物兼交友，它可以加入团长开的团，管理自身的订单，查阅信息并与他人对话。系统功能结构如下图4-2所示：
图4-2系统功能结构图
4.3 业务流程设计
4.3.1 开团信息审核流程设计
团长发布开团信息之后，就处于等待审核的状态，管理员在待审核里浏览开团的信息，依据平台的规定来确定内容是否符合规则，如果审核成功，就将信息置为已审核并且进行展示，团长与用户可以看见。如果审核失败，则管理员要填入驳回理由，信息退回团长进行修改。经过这样的步骤保证了平台内容的规范化。开团信息审核流程图如图4-3所示。
图4-3开团信息审核流程图
4.3.2 工厂打样对接流程设计
团长查看工厂信息之后可以向所选中的工厂发出打样的申请并上传设计图纸，工厂端接收到申请后审查自身产能及设计能力能否达到图纸的要求，工厂方面可以选择同意或者不同意打样，如果同意那么就开始进行打样的制作，完成后上传打样的产品和质检证书等；如果不认同，那么要填写回复通知团长，团长根据样品的情况确定是否开始大批量的合作。这是个性化定制的重要一环。工厂打样对接流程图如图4-4所示。
图4-4工厂打样对接流程图
4.3.3 用户参团购买流程设计
顾客查看发布过的公开开团信息，挑选自己心仪的产品点击进入产品详情页面。顾客决定购买之后便要进行购产品的规格和数量以及填写收获地址，然后系统会算出总计金额。顾客核对订单信息后选择支付方式进行付款。付款成功后系统就会产生一个参团购买记录，订单此时处于待发货的状态。团长收到订单以后就会开始安排发货。这一系列的操作实现了从浏览产品到下单付款的最主要的购物过程。用户参团购买流程图如下图4-5所示。
图4-5用户参团购买流程图
4.3.4 订单发货流程设计
待开团商品满足发货条件时，团长需要进行待发货订单处理，团长对订单发货处理页面内进行订单选择并录入或者上传运单信息包括快递公司以及单号，提交之后，订单状态变为已发货，同时物流信息也会被更新；而在此订单购买者即普通用户可以在自身的参团购买记录里面查看相关物流状况。顾客收到货品之后可以在系统内点击确认收货，订单状态闭环，完成了买家对于订单从卖家处发出的物流轨迹追踪。订单发货流程图如图4-6所示。
图4-6订单发货流程图
4.3.5 周边商品上架流程设计
工厂用户或团长用户可以在自己的商城管理里面增加商品。用户进入到增加页面，在这里输入商品的基本信息例如：标题，描述，价格，库存等等；然后上传一张商品封面及若干商品详情图片；最后进行商品规格参数设置。这些都填写完之后提交，商品就处于待上线或者草稿状态，用户可以对自己发布的商品进行上线操作，一旦上线成功，则会在其对应的位置的周边商城里出现可以被其他用户查看并购买。这个流程控制的就是自营产品的发布流程。周边商品上架流程图如下图4-7所示。
图4-7周边商品上架流程图
4.4 数据库设计
数据库的设计过程中使用ER图把概念模型转化为具体的数据模型。这个步骤就是要确定每个数据表的字段及类型，约束，还有各个表之间所对应的关系，为下一阶段的物理设计做好准备。然后才进行优化数据存储策略的研究，使得系统性能高而且有伸缩性。
4.4.1 数据库概念结构设计
构架"同人周边订单管理系统"的概念模型，核心是从中提炼出"团长"、"工厂"、"用户"及相关"商品订单"的时序互动。团长发送带有商品明细的"开团"，吸纳若干个"用户"加入构成"购买订单"。团长还要负责与"工厂"关于"打样"联络，落实加工问题。工厂还可以自主在"商城"上货20。系统必须明确上述对象之间一对多或多元关系，比如一个开团对应多个参团订单，一个工厂对应多个打样需求。概念模型是对现实世界的第一次信息层面的抽象，通过实体、属性和相互间的关系来刻画，它为下一步数据库的逻辑结构设计提供了理想的、独立于具体技术实现的数据视角。而E-R图为描述概念模型提供了良好的工具。根据上述思路勾勒出整个系统的E-R图，作为逻辑建模的基础。整体的ER图如下图4-8所示：
图4-8系统E-R图
（1）用户实体主要由用户id、用户名、密码、昵称这些属性构成。如下图4-9所示。
图4-9用户实体属性图
（2）团长用户实体主要是团长用户id、用户id、团长姓名、审核状态这些属性组成。如下图4-10所示。
图4-10团长用户实体属性图
（3）工厂用户实体主要是由工厂用户id、用户id、工厂名、审核状态等属性组成。如下图4-11所示。
图4-11工厂用户实体属性图
（4）普通用户实体主要有一般用户id、用户id、用户名、用户手机等属性。如下图4-12所示：
图4-12普通用户实体属性图
（5）开团信息体主要由开团信息id、团长用户、商品名称、审核状态这些属性构成。如图4-13所示。
图4-13开团信息实体属性图
（6）参团购实体主要由参团购id、普通客户、开团信息、购买数量这些属性构成。如图4-14所示。
图4-14参团购买实体属性图
(7)订单发货实体主要由订单发货id、参团购买、快递单号、备注信息等属性构成。如图4-15所示。
图4-15订单发货实体属性图
（8）工厂信息实体主要包含了工厂信息id、工厂用户、生产能力、生产价格等属性。如下图4-16所示：
图4-16工厂信息实体属性图
（9）工厂打样实体主要有工厂打样id、团长用户、工厂用户、设计图稿等功能属性。如图4-17所示。
图4-17工厂打样实体属性图
（10）打样对接实体主要包含打样对接id、工厂打样、打样成品、审核状态等属性。如图4-18所示。
图4-18打样对接实体属性图
（11）周边商城实体主要是指周边商城id、工厂用户、商品标题、商品库存等属性。如下图4-19所示。
图4-19周边商城实体属性图
4.4.2 数据库逻辑结构设计
数据库逻辑设计方案是将概念结构转化为某个具体数据库管理系统支持下的关系模型。该方案的设计遵守第三范式规则，尽可能的降低数据冗余程度，达到数据一致性的目的。每一个实体对应一个数据库表，而实体属性则对应字段并确立主键；对于实体之间的参照则采用外键约束，例如："参团购买"的数据表就是由"开团信息id"，"普通用户id"两个外键分别与"开团信息"，"普通用户"这两个数据库表相关联。针对多个对象之间的多重关系，例如业务所蕴含的复杂联系，则增加中间表或者借助当前所用表的两个外键联合表示。设计过程中还需兼顾查询效率，特定情况下为了提高查询效率可以适当地保留冗余字段。每个表都应有明确字段名、字段类型、字段长度以及非空等限制条件。
（1）用户表主要用于保存系统的全部已注册用户的用户基本信息。主要字段有用户id、用户名、密码、昵称等。如下表4-1所示。
表4-1用户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 用户id | int | 11 | 主键 |
| 2 | 用户名 | varchar | 16 | 登录账号 |
| 3 | 密码 | varchar | 64 | 加密存储 |
| 4 | 昵称 | varchar | 16 | 显示名称 |
| 5 | 头像 | varchar | 255 | 头像图片地址 |
| 6 | 创建时间 | timestamp | - | 记录创建时间 |
（2）团长用户表主要用于保存团长用户的扩展业务数据，关联基础用户。主要包含团长用户id、用户id、团长姓名、审核状态这些属性。如表4-2所示。
表4-2团长用户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 团长用户id | int | 11 | 主键 |
| 2 | 用户id | int | 11 | 外键，关联用户表 |
| 3 | 团长姓名 | varchar | 64 | 团长真实或化名 |
| 4 | 联系方式 | varchar | 64 | 团长联系电话等 |
| 5 | 审核状态 | varchar | 16 | 如：待审核、通过、未通过 |
| 6 | 创建时间 | datetime | - | 记录创建时间 |
（3）工厂用户表主要作用是用于保存工厂用户的拓展业务信息，绑定基本用户。主要有工厂用户id，用户id，工厂名，审核状态等属性，如表4-3所示。
表4-3工厂用户表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 工厂用户id | int | 11 | 主键 |
| 2 | 用户id | int | 11 | 外键，关联用户表 |
| 3 | 工厂名称 | varchar | 64 | 工厂或工作室名称 |
| 4 | 工厂电话 | varchar | 64 | 联系方式 |
| 5 | 审核状态 | varchar | 16 | 如：待审核、通过、未通过 |
| 6 | 创建时间 | datetime | - | 记录创建时间 |
（4）开团信息表主要是用于保存团长发起的商品开团项目信息。主要包含开团信息id、团长用户、商品名称、审核状态、可参团人数等属性。如下表4-4所示。
表4-4开团信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 开团信息id | int | 11 | 主键 |
| 2 | 团长用户 | int | 11 | 外键，关联团长用户 |
| 3 | 商品名称 | varchar | 64 | 开团商品名称 |
| 4 | 宣传图稿 | varchar | 255 | 商品宣传图片 |
| 5 | 开团期限 | varchar | 64 | 开团截止时间 |
| 6 | 可参团人数 | double | - | 最多参与人数 |
| 7 | 审核状态 | varchar | 16 | 如：待审核、通过、未通过 |
| 8 | 审核回复 | varchar | 255 | 管理员审核意见 |
| 9 | 创建时间 | datetime | - | 记录创建时间 |
（5）参团购买表主要作用是保存普通用户参与开团之后产生的购买记录。主要有参团购买id、普通用户、开团信息、购买数量、支付情况这些属性。如表4-5所示。
表4-5参团购买表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 参团购买id | int | 11 | 主键 |
| 2 | 普通用户 | int | 11 | 外键，关联普通用户 |
| 3 | 开团信息 | int | 11 | 外键，关联开团信息 |
| 4 | 购买数量 | double | - | 购买商品数量 |
| 5 | 收货地址 | text | 65535 | 用户收货地址 |
| 6 | 支付状态 | varchar | 16 | 如：待支付、已支付、已退款 |
| 7 | 购买日期 | date | - | 下单日期 |
| 8 | 创建时间 | datetime | - | 记录创建时间 |
（6）订单发货表主要是用于存放参团订单所对应的物流发货信息。主要有订单发货id、参团购买、快递单号、备注信息等属性。如下表4-6所示。
表4-6订单发货表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 订单发货id | int | 11 | 主键 |
| 2 | 参团购买 | int | 11 | 外键，关联参团购买 |
| 3 | 快递单号 | varchar | 64 | 物流运单号 |
| 4 | 质检报告 | varchar | 255 | 质检报告文件地址 |
| 5 | 备注信息 | text | 65535 | 发货备注 |
| 6 | 创建时间 | datetime | - | 记录创建时间 |
（7）工厂信息表主要用于保存工厂用户所维护的自身的产能及报价信息。主要有工厂信息id，工厂用户，产能，生产价格等属性。见表4-7所示。
表4-7工厂信息表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 工厂信息id | int | 11 | 主键 |
| 2 | 工厂用户 | int | 11 | 外键，关联工厂用户 |
| 3 | 生产能力 | varchar | 64 | 描述产能规模 |
| 4 | 可生产种类 | varchar | 64 | 擅长的产品类型 |
| 5 | 生产价格 | double | - | 大致报价范围或标准 |
| 6 | 工厂简介 | longtext | 4294967295 | 详细介绍 |
| 7 | 更新时间 | timestamp | - | 最后修改时间 |
（8）工厂打样表主要是用于保存团长发给工厂的打样申请信息记录。主要包含工厂打样id、团长用户、工厂用户、设计图稿、审核状态这几个属性。如表4-8所示。
表4-8工厂打样表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 工厂打样id | int | 11 | 主键 |
| 2 | 团长用户 | int | 11 | 外键，关联团长用户 |
| 3 | 工厂用户 | int | 11 | 外键，关联工厂用户 |
| 4 | 设计图稿 | varchar | 255 | 设计稿文件地址 |
| 5 | 质检方式 | varchar | 64 | 期望的质检标准 |
| 6 | 打样备注 | text | 65535 | 申请备注 |
| 7 | 审核状态 | varchar | 16 | 工厂审核状态 |
| 8 | 创建时间 | datetime | - | 记录创建时间 |
（9）打样对接表主要用于保存工厂做完打样之后跟团长确认成品的结果的信息。主要有打样对接id、工厂打样、打样成品、审核状态这些属性。如下表4-9所示。
表4-9打样对接表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 打样对接id | int | 11 | 主键 |
| 2 | 工厂打样 | int | 11 | 外键，关联工厂打样 |
| 3 | 打样成品 | varchar | 255 | 成品图片或文件地址 |
| 4 | 质检报告 | varchar | 255 | 工厂提供的质检报告 |
| 5 | 审核状态 | varchar | 16 | 团长对成品的确认状态 |
| 6 | 审核回复 | varchar | 255 | 团长回复意见 |
| 7 | 创建时间 | datetime | - | 记录创建时间 |
（10）周边商城表主要用于保存工厂用户所上架的自营商品的信息。主要有周边商城id、工厂用户、商品标题、商品库存、商品价格这些属性。如下表4-10所示。
表4-10周边商城表
| 序号 | 字段名 | 数据类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | 周边商城id | int | 11 | 主键 |
| 2 | 工厂用户 | int | 11 | 外键，关联工厂用户 |
| 3 | 商品标题 | varchar | 125 | 商品名称 |
| 4 | 封面图 | text | 65535 | 商品主图 |
| 5 | 商品库存 | int | 11 | 可用库存数量 |
| 6 | 商品价格 | double | - | 销售价格 |
| 7 | 商品原价 | double | - | 划线原价 |
| 8 | 上架状态 | smallint | - | 0：下架；1：上架 |
| 9 | 创建时间 | datetime | - | 记录创建时间 |
4.4.3 系统数据流图
（1）顶层数据流图：顶层数据流图指明系统的边界，是系统与外界的接口，是整个系统的概括。本系统的外部实体有管理员、厂方用户、团长用户以及普通用户。管理员同"同人周边订单管理系统"进行交互，管理平台基本秩序；厂方用户与系统之间进行交互，承接订单生产管理产品；团长用户在系统中发起和管理项目并且能够把制造需求分享给厂方用户；普通用户在系统中参与购买和社交活动。如图4-20所示：
F1系统管理指令F2订单发货指令F3厂商资质认证指令
F4生产能力信息F5打样与商品审核F6商品上架信息
F7打样与开团申请F8项目与商品管理F9商品购买请求
F10资讯浏览与互动F11订单状态与物流F12社交沟通消息
图4-20同人周边订单管理系统顶层数据流图
（2）一级细化数据流图：一级细化数据流图是在顶层数据流图的基础上将处理的功能进一步细分。该系统被划分为6大主要的综合性功能，分别是P1项目发布与审核、P2生产对接与商品上架、P3商城浏览与购买、P4订单处理与物流、P5资讯社区互动、P6用户聊天与沟通。管理员在"同人周边订单管理系统"上审核团长发布的项目以及工厂上传的资质并对交易秩序进行监管；团长在系统里搜寻工厂并发布、管理项目；工厂从系统里接受生产订单并上架产品；普通客户群体在这个系统里进行商品的浏览购买以及社区讨论等等，详情如下图4-21所示：
F1项目审核指令F2工厂审核指令F3生产信息维护F4打样对接数据
F5商品数据F6项目/商品查询F7订单数据F8物流数据
F9资讯互动数据F10聊天数据
图4-21同人周边订单管理系统一级细化数据流图
第五章 系统实现
5.1 管理员功能实现
5.1.1 开团信息管理功能实现
超级管理员用户从前端页面发出查询请求，由系统的后台开团信息控制层接受到这个查询请求，控制层分析请求参数并调用业务逻辑层中的开团信息业务。业务层根据参数设置数据查询对象并调用相应数据访问层。数据访问层向数据库发出结构化查询语句指令获得开团信息表记录集。然后返回给前端页面依次经过数据访问层映射成实体类对象、业务层封装成业务模型、控制层组成响应数据，最后返回至前端界面动态加载显示。审批、删除等操作流程走的是类似的路径，业务处理层在更新或者删除数据之前会做相应的状态判断及权限检查。开团信息管理时序图如图所示：
图5-1开团信息管理时序图
系统为管理员提供了开团信息的集中管理界面。界面主体是一个表格，展示了开团项目的名称、发起团长与创建时间。表格上方设有查询框与状态筛选器，管理员输入关键词或选择状态后点击查询按钮，列表内容即时刷新。每条记录后方配有操作按钮，点击详情按钮弹窗展示该项目的完整图文详情。审核按钮引导至审核页面，页面内提供"通过"与"不通过"的单选框以及用于填写具体意见的文本域。删除按钮触发二次确认对话框，防止误操作。整个界面布局清晰，关键操作醒目。开团信息管理界面如图5-2所示。
图5-2开团信息管理界面
5.1.2 参团购买管理功能实现
管理员想要浏览用户参团记录时候，前端发出列表查询请求，参团购买控制器接受请求，获取到分页、条件信息。它委派给参团购买服务，执行业务逻辑，服务请求参团购买数据映射器。它进行多表联合查询，涉及参团购买表、用户表、开团信息表，数据库处理查询，得到组合数据。数据逆向上传，服务层对数据进行了汇总统计，控制器将结果包装成模型返回。管理员进行详情浏览，或者进行记录删除时候，系统通过唯一的参团购买标识找到准确的数据记录，会触发声明相应的查询或者删除请求调用链，保证操作精确性和数据一致性。参团购买管理时序图见下图5-3所示：
图5-3参团购买管理时序图
组团购买管理页面展示了全部用户的下单情况。页面采用了卡片列表结合表格的形式进行展示，每一个卡片都简要展示了这一次购买的重要内容：购买的商品名、参团用户的昵称、支付金额以及订单的状态。页面上方提供的根据支付状态进行筛选的下拉框，管理者可迅速找到待支付、已支付或已退款等不同类型的订单。单击任一个卡片，在右侧会弹出这个订单的具体细节，包括收货的地址，购买的数量，支付的流水号。卡片右下方有一个垃圾桶图标，即为删除键，用于清除无用或者测试订单，单击之后这个卡片会被移除此列表。页面可根据购买的时间降序排序。组团购买管理页如图5-4所示。
图5-4参团购买管理界面
5.1.3 订单发货管理功能实现
管理员在前端点击进入订单发货管理界面，系统默认加载初始列表，发起一次查询请求。订单发货控制器接收入口，调用相应业务服务。业务服务在进行处理逻辑的同时不仅对订单发货表发起查询还通过数据映射器联表了参团购买表来获得商品及用户的相关信息从而构成一条完整的信息展示视图。数据库进行关联操作之后返回结果集。针对数据导出的操作请求，控制器接受时间区间值，业务服务向数据映射器发送指令查询这段时间内的全部有关数据并由工具类将其转化为excel的工作簿流。控制器设置响应头，设置文件类型与文件名，最后将文件流写回响应体实现文件下载功能。订单发货管理时序图如图5-5所示。
图5-5订单发货管理时序图
此界面用于对订单的物流状况查询和处理，主体是一个关于运单编号、收件人、发货日期和当前最新物流状态等信息的一个列表，每一列之前都有复选框可以选择进行批量操作，在这个表格上方有日期筛选器还有"导出"键，管理员选定日期之后点击导出浏览器即自动下载一个含有被选中全部订单的物流信息EXCEL文档。点击具体一行的"详情"按键，则在页面底部会出现一个抽屉式的面板，在其中也会嵌套显示出该条订单所对应的产品、买家、完整的物流动态记录等等信息。界面色彩以绿色表示已经签收的订单，以黄色表示正在运输途中的订单，清晰明了。订单发货管理界面如下图5-6所示：
图5-6订单发货管理界面
5.1.4 工厂信息管理功能实现
管理员浏览工厂列表的请求发送到工厂信息控制层，控制层把任务委托给工厂信息服务层，服务层构造查询对象，工厂信息数据访问器被调用，其查询工厂信息表并结合业务要求连接工厂用户表来获得账户状态，数据库返回工厂资质信息。在管理员进行审核操作时，前端发送工厂编号以及审核结果。控制层接收到数据以后服务层先核实此工厂是否为等待审核的状态，确认之后就设置工厂信息表中的审核状态字段，在此期间可能会调用消息服务告知相应的工厂用户，审核操作在一个数据库事物内完成，确保了状态变化的原子性。工厂信息管理时序图如下图5-7所示。
图5-7工厂信息管理时序图
工厂信息审核页面整齐有序地排列出当前所有申请的工厂，页面左边是可收起的侧边栏，根据工厂类别实现快速分类查看。主区域每一个工厂都是一个独立的证件卡片样式，正面是工厂名、营业执照缩略图以及申请时间，点击即可翻开到反面，显示出工厂自行填写上传的具体生产能力介绍、生产种类及联系方式。卡片下方有两个显眼的操作按钮："通过"按钮绿色，"不通过"按钮红色，点击任意一个按钮后该卡片就会变为半透明状态并且显示已经处理，避免重复操作。页面上方设有搜索框可以根据工厂名称进行模糊查找，工厂信息管理页面如下图5-8所示。
图5-8工厂信息管理界面
5.1.5 工厂打样管理功能实现
管理员在页面上浏览工厂打样申请列表，系统向工厂打样controller提出查询请求，controller委托工厂打样service，service通过工厂打样data mapper对数据库发出查询命令。data mapper进行的查询语句同时关联了工厂打样表、团长用户表以及工厂信息表来获得完整申请背景，数据库返回关联查询的结果集。针对删除功能，管理员点击删除按钮，前端提交附带打样记录唯一码的删除指令，controller将此任务转发service层。service层经过一系列业务规则验证之后转向对data mapper发出删除命令，由其在工厂打样表内清除相关记录保证列表的数据精简高效。工厂打样管理时序图如图5-9所示。
图5-9工厂打样管理时序图
工厂打样管理界面是用于查看团长对工厂发起的打样申请流。界面的时间轴结合看板形式设计。界面中部有一垂直时间轴，在时间轴上的每一个重要申请，审核和结束节点，在时间轴上都有一个时间节点。右侧是一个看板面板，把处于各种状态下的申请分成三栏，"待处理"，"进行中"，"已完结"，管理者可以在各栏之间随意拖动卡片来改变其状态。点击任意卡片都会弹出一个模态对话框，在对话框内展示当前申请的设计图纸预览，团长提交的质量标准要求和双方聊天历史记录。此界面可以根据工厂名或者团长名字来进行过滤。工厂打样管理界面如图5-10所示。
图5-10工厂打样管理界面
5.1.6 打样对接管理功能实现
管理员需要查看打样对接进度时候触发了打样对接控制器，控制器启动打样对接的服务层调用了相应的数据映射器。数据映射器向打样对接表发起了查询操作并且与工厂打样表进行了左连接以获得前置申请信息形成了一个点到点的视图，数据库执行查询返回了结果集。在管理员选择要清除一条对接信息的时候就发出了删除请求，控制器捕获了这个删除请求，在服务层在做出删除操作之前判断这条对接的状态是否已经是最终节点，防止删除未结束的业务流，检验无误之后发出指令给数据映射器让它在打样对接表中清除了对应的那一条数据。打样对接管理顺序图如图5-11所示：
图5-11打样对接管理时序图
此界面是对打样申请被工厂接收后的成品对接进行处理。界面的大部分是一个画廊风格的网格结构，每一个网格就是一个打样对接。每个网格内有打样成品主图缩略图、工厂名、对接时间、一个用于表示此次对接结果的勋章。在列表页每个网格下方都有一个删除图标按钮。打样对接管理界面如下图5-12所示。
图5-12打样对接管理界面
5.2 工厂用户功能实现
5.2.1 工厂信息管理功能实现
厂方用户登录之后进入自身的信息管理界面，前端默认获取当前厂方信息，向工厂信息控制发送查询请求消息。控制将请求委派给工厂信息服务，服务依据当前登录用户的身份标志向数据映射器发出寻对应厂方信息记录的消息。数据库反馈此厂方的具体数据。在厂方用户修改信息并提交之后，控器接受携带新的字段值的数据传输对象，服务端进行校验数据的有效性，例如价钱不能小于0等，然后服务再委托数据映射器的更新操作将新的数据存储至工厂信息表中，更新操作保证了仅此厂方用户可以修改自身的数据。工厂信息管理时序图如图5-13所示。
图5-13工厂信息管理时序图
工厂用户在此界面对自身的展示主页进行管理维护。界面仿制了一个可编辑的个人主页的样子。页面上方为工厂名及Logo上传处。下面有几个不同的可编辑模块："生产力"模块中用户可以输入文字说明或者单选产能标签；"可生产种类"模块是一个标签输入框，用户自由增加或减少产品种类标签；"生产价格"模块有一个价格范围滑动条或输入框；"工厂简介"模块是一个完整的富文本编辑器，包括了字体、排版、插入图片，用来制作详细全面的介绍页。每个模块旁边有一个"编辑"按键，单击后此模块变成交互模式，编辑结束后点击保存即刻更新。工厂信息管理界面如下图所示：图5-14。
图5-14工厂信息管理界面
5.2.2 工厂打样管理功能实现
厂用户浏览接收到的打样申请信息列表，要求工厂打样控制器进行处理。控制器获取当前登录的工厂用户的标识，将其作为核心搜索条件交给工厂打样服务进行查询。服务组织查询语句，明确只要求查询到收件人为当前工厂的申请信息。工厂打样数据映射器依据条件向数据库发出查询，得到符合条件的申请信息条目集合。这一业务流程体现了数据隔离机制，不同的工厂用户只能阅览属于自己的申请信息，具有较强的保密性和针对性。工厂打样管理顺序图如下图5-15所示。
图5-15工厂打样管理时序图
该页面为厂方用户处理外来打样申请的工作台。页面左边是侧边栏，纵向排列着"新申请"，"已评估"，"已拒绝"等各类申请状态标签。主体部分则是以列表的形式展示着所有申请的信息，每个申请都简单明了，只有项目申请名，团长名字，申请时间以及一个表示紧急状态的彩点。厂方用户可点击列表中的"查看"，弹出的小窗口即为团长上传的设计图稿文件，质检方式需求与附言内容。该页面支持批量操作，厂方可勾选若干条申请，然后统一带动设置为"已读"或其他状态类别。搜索框可根据团长昵称、项目名迅速定位目标。工厂信息管理界面如图5-16所示。
图5-16工厂信息管理界面
5.2.3 打样对接管理功能实现
工厂用户在上传打样之后进行对接管理模块下上传成品。上传的动作发出请求到打样对接控制器。控制器接受一个包括成品文件id、质检报告等等的信息对象，它委托打样对接服务。服务首先检查此条打样记录是否允许上传，然后对文件存储做业务处理并且将对接状态改为"待团长确认"，此时数据映射器做插入或者更新操作，向打样对接表新增一条记录。而团长回复之后，工厂用户查看回复内容时候，控制会委托服务查询此条对接以及相关的团长回复内容，得到完整的对话上下文。打样对接管理时序图如图5-17所示。
图5-17打样对接管理时序图
该界面为工厂端上传打版结果与团长交流的地方。界面以聊天线程形式排列。每一个正在处理当中的打版任务就是一个聊天线程。线程上方展示该任务的任务基本信息。下方分为左右两个区域：左半部分为工厂操作栏，包括"上传成品图片"、"上传质检报告PDF"的上传控件以及一个用于输入备注的长文本输入框，操作栏末端有一个"提交审核"按钮；右半部分则是聊天消息历史记录面板，按照时间顺序列出工厂上传的各种文件、团长回复的文字内容、双方审核状态变化记录等。已经结束的聊天线程会自动收起，保持页面整洁。打版对接管理界面如下图5-18所示。
图5-18打样对接管理界面
5.2.4 商城管理功能实现
工厂商户管理自有商品时，列表查询请求由商城商品控制类拦截。控制类将当前工厂商户的身份标识与查询条件一起传入商城商品服务类。服务类负责保证查询结果仅限于本工厂发布商品，并向商城商品数据映射类发起请求。数据映射类查询周边商城表并将发帖人即为当前用户的结果筛选返回；而新增商品时，控制类获取到的是携带多图、规格等复杂数据的表单类对象，服务类需要完成文件上传到服务器、规格数据序列化等业务逻辑操作后再交由数据映射类将商品信息存储进数据库。删除时进行商品所有者及工厂身份双重校验。商城运营管理时序如下图5-19所示。
图5-19商城管理时序图
5.3 团长用户功能实现
5.3.1 查看工厂信息功能实现
团长用户查看工厂列表查找生产者，此请求由工厂信息控制器接收。工厂信息控制器调用工厂信息服务，服务层查询全部通过平台审核的工厂信息。数据映射器执行数据库查询操作，在工厂信息表内取得状态值为"已通过"的所有记录。数据回传后由前端渲染。团长选中某一个工厂之后点击"申请打样"的话就会在前端页面跳转到打样申请表单页。提交打样申请的操作会发送请求到工厂打样控制器，控制器新建一条打样申请记录并将状态置为"待工厂处理"，挂载当前团长以及对应工厂。查看工厂信息时序图如图5-21所示。
图5-21查看工厂信息时序图
团长客户从这个界面中发现并考察意向合作工厂。界面布局类似于企业黄页或者采购网站。首页有一个巨大的搜索框，团长客户可以直接在其中键入工厂名准确查找。下面是工厂筛选模块，可以根据"可生产种类"、"生产价格区间"、"生产能力等级"等多项指标来对工厂进行检索筛选。主体内容区域用卡片的形式排列出所有符合筛选条件的工厂，每个卡片重点展示工厂名字、主打品类、价格区间和一个综合性评分。点击卡片时，页面会顺畅地展开一个侧滑抽屉，在其中呈现这个工厂的详尽介绍、作品案例图片墙、其他团长客户的点评还有个突出的"发起打样申请"按钮。界面允许客户把感兴趣的工厂收藏到收藏夹里。浏览工厂信息界面如下图5-22所示。
图5-22查看工厂信息界面
5.3.2 查看开团信息功能实现
团长对自己发布的开团进行管理，查询请求由开团信息控制层负责处理。控制层需要获取到当前登录的团长信息，并将其作为查询条件之一交给开团信息服务层。服务层通过数据映射层在开团信息表内查询所有发布人ID是当前团长ID的记录。数据展示给团长。团长发布新的开团，提交的复杂表单数据由控制器层接受，服务层负责处理图片上传、富文本内容净化并将完整的开团信息发布至数据库，状态设为"待审核"，删除操作也会验证权限并进行记录删除。查看开团的信息时序如下图5-23所示。
图5-23查看开团信息时序图
这是团长用户对自己发起的所有开团项目的集中工作台。页面为仪表板式的设计布局。中部是一个可视化的项目时间轴，清晰地显示出各个开团项目所处的"筹备中"、"审核中"、"进行中"、"已结束"的全流程状态节点。时间轴下方是项目卡片列表，卡片内有项目封面小图、标题、当前参与数/总目标数、剩余时间和项目标签。点击"创建新开团"，则会切换成一个沉浸式的编辑页面，页面分区明显：左侧是表单，依次录入商品名称、选取封面图、设定开团截至日期、人数上限等信息；右侧是一个实时预览面板，同步显示出编辑后商品详情富文本的效果。已经结束的项目会被收纳进独立标签页内。查看开团信息界面如下图5-24所示。
图5-24查看开团信息界面
5.3.3 商城管理功能实现
团长管理自己经营的周边商城，商品列表查询请求到达团长商城控制器，控制器判定团长身份，请求团长商城服务，服务层查询周边商城表下该团长的所有商品信息数据，数据映射器进行查询返回；上架商品流程同工厂端相似，只是商品记录的归属字段置为当前团长，团长查看商品详情页及评论的时候，控制器查询指定商品ID的商品详细数据以及对应用户评论数据，给用户呈现完整的商品展示面。商城经营管理类时序图如下图5-25所示：
图5-25商城管理时序图
团长端的商品自营商城管理界面也与厂家端相似，只是更偏向于零售，界面左边侧边栏有"正在热卖"、"售罄"、"库存中"等类别，商品列表采用更为精简的表格模式方便管理更多的商品，列表的列分别为缩略图、商品名称、规格、单价、库存数量、销售量还有操作列。点击行的操作栏里的"详情"，右侧会滑动出来一个窗口，在这个窗口里除了商品的信息，还有一个小标签叫做"评论管理"，团长可以通过这里看到客户对自己这个商品的所有评论，也可以进行公开回复或者隐藏不良评论。上架商品也是一样的多步骤向导式，不过已经填充好的店铺信息就是团长本人的品牌了。商产管理界面如下图5-26所示：
图5-26商城管理界面
5.3.4 查看周边商城功能实现
团长用户作为买家浏览平台上的周边商城时，查询请求被发送至周边商城控制器。控制器接收可能包含关键词、排序方式等参数的请求，调用周边商城服务。服务层处理这些参数，构造相应的数据库查询条件。周边商城数据映射器执行查询，可能涉及按价格、销量排序或按商品标题模糊匹配。数据库返回商品列表数据。当团长用户将商品加入购物车或直接购买时，系统会调用购物车或订单服务的相应接口，创建购物车项或生成订单，这些操作涉及不同的业务控制器与服务。查看周边商城时序图如图5-27所示。
图5-27查看周边商城时序图
此界面是团长用户作为普通消费者浏览和购买商品的商城首页。界面风格与主流电商平台一致。顶部有大型横幅广告位与商品分类导航。页面主体是瀑布流式的商品feed流，每个商品卡片设计精美，展示主图、标题、现价和原价。卡片右上角有收藏按钮。页面左上角提供排序方式下拉菜单，如"按最新上架"、"按价格从低到高"、"按销量"排序。搜索框位于页面顶部中央，支持输入关键词进行全局搜索。点击任意商品卡片，会进入商品详情页，详情页内可以选择商品规格、查看详细图文介绍、浏览用户评价，并有"加入购物车"与"立即购买"的明显按钮。查看周边商城界面如图5-28所示。
图5-28查看周边商城界面
5.3.5 查看在线聊天功能实现
团长用户在使用即时聊天的过程中，前端WebSocket客户端保持与服务器的长链接状态，团长发出的一条消息即由WebSocket链接发送给后台中的消息处理程序，消息处理程序负责读取消息体并解析出接收用户，将消息的内容、发送者、接收者以及时间戳等信息保存进消息记录表；与此同时，处理器也尝试通过WebSocket连接将消息即时推送在线的好友用户。而团长查看聊天记录或者好友列表时便发起HTTP请求，请求聊天控制层，聊天控制层再调用聊天服务向数据库查询历史消息或好友关系信息。观察在线聊天时序图如图5-29所示。
图5-29查看在线聊天时序图
在线聊天界面是独立的一个漂浮窗口可最小化缩放在屏幕角落。此窗口左边为好友列表，在列表中的条目显示好友头像、昵称、最近一条消息预览。单击某一好友，则右边主聊天界面显示与此好友的消息历史记录。主聊天界面顶部显示好友信息，下面是消息显示区，消息以气泡的形式排列在左右两侧区分自己的消息与收到的消息。底部为消息输入框，在输入框右侧有两个按钮分别为表情选择按钮、发送按钮。好友列表上方有一个添加好友的按钮，点击后会出现一个搜索框，在其中输入其它用户昵称或ID可以向其发送好友请求。窗口支持发送文字消息以及常用的表情符号。查看在线聊天界面如图5-30所示。
图5-30查看在线聊天界面
5.4 用户功能实现
5.4.1 查看在线聊天功能实现
普通用户的聊天功能交互流程与团长用户大致相同，都采用了WebSocket进行即时通讯。当用户发送消息时，消息内容会经过由WebSocket通道传输到服务端消息处理器，处理器校验发送者的身份并将此条消息存储到数据库中的消息表内，并立即寻找到接收者的在线连接，若此时接收者处于在线状态，则会即时将消息经其WebSocket通道推送给对方，若是离线则会在其日后上线时拉取消息。而用户查看好友列表或历史记录则会发起一个常规的HTTP请求，由聊天控制器协调聊天服务完成数据库查询操作并返回结果。浏览在线聊天时序图如下图5-31所示。
图5-31查看在线聊天时序图
普通用户聊天界面与团长用户界面的功能、排版也完全一致，为了提供相同的用户体验。它是一个能够随意拉动、拉伸的悬浮框。左边垂直列表是全部已添加好的好友，每一个好友单元格都有一个未读消息数量徽章标识；右边聊天主窗口则是被选中的好友对话内容，在对话气泡里时间顺序排列支持图片预览。底下输入框支持粘贴文字，在输入框旁边的"+"号按钮能开启一个展开菜单，里面有发送图片、文件等功能选项。整个界面颜色都很轻柔，提示声音也可设定。查看在线聊天界面如图5-32所示。
图5-32查看在线聊天界面
5.4.2 查看开团信息功能实现
普通用户在商城浏览开团信息，页面加载时自动发送查询请求至开团信息控制器。控制器调用开团信息服务，服务层筛选出状态为"已通过"且仍在开团期限内的项目。数据映射器执行查询并可能关联团长信息表。用户进行关键词搜索或使用筛选器时，新的请求携带这些参数，服务层将其整合进查询条件，数据映射器执行更精确的搜索。当用户点击某个开团项目并决定参团购买时，会跳转到订单创建流程，该流程由订单控制器处理，涉及库存检查、订单生成等系列服务调用。查看开团信息时序图如图5-33所示。
图5-33查看开团信息时序图
这是大众用户发现并参与兴趣项目的最主要页面。整个界面设计具有极强的社区氛围以及紧张感。顶部即是大张的、轮播形式的热开项目海报名片，下面是项目的过滤栏，可按作品种类、价位段、剩余时长迅速对项目进行过滤。主体的内容区域采用了卡片墙的方式来呈现正在开团的项目，卡片着重展现了美丽的宣传图，项目的名称，当前参与的人数进度，倒计时。将鼠标移至卡片之上会产生放大效果，点击卡片则进入到该项目的信息页，在信息页中用户能点赞、收藏该项目，页面中明显的地方有一个大大的"立即参团"按钮，点击参团之后弹出一个轻量级的表单层，让用户确定购买数目、录入或选取收货地址，引导支付。查看开团信息界面如图5-34所示。
图5-34查看开团信息界面
5.4.3 查看参团购买功能实现
顾客在查看自身的参团购记录时候，请求发送到参团购买控制，控制器需要获取当前登录用户的标识信息，将之作为主要查询依据传入参团购买服务，服务调用数据映射器，在参团购买表内查询全部购买者ID为此用户ID记录，数据回传后按支付状况等字段区分显示；用户确认收货以及上传物流证明时候，控制接受更新操作，服务判断订单状态、用户操作权限后，数据映射器更新订单表内物流状态或者相关证据。浏览参团购时序图如图5-35所示：
图5-35查看参团购买时序图
该页面为用户个人订单中心。页面使用了标签页的设计，由"待付款"，"待发货"，"待收货"，"已完成"等一系列不同的状态页组成，用户点击标签即可进行跳转。每一个订单就是一个包裹卡片，在这个卡片中展示了产品的缩略图，产品名称，订单编号，实际支付金额以及最醒目的状态标签。点击卡片内的"详情"按钮，在伸展区域会展示这条订单的具体详情：产品规格、收货地址及支付方式、完整的物流追踪记录等。"待收货"的订单在卡片处有一个"确认收货"的按钮；而对于需要顾客自己发出货物的订单则有"上传发货凭证"的按钮，点击后可以上载快递单的照片。查看参团购买页面如下图5-36所示。
图5-36查看参团购买界面
5.4.4 查看周边资讯功能实现
顾客阅读附近信息，查询请求到达文章信息控制层，控制层调用文章信息服务层，服务层可能会对信息类别或者热度进行数据过滤。文章数据映射器在文章表中查询信息列表，顾客点击查看某个具体的信息详情，详情查询请求发送到服务层，服务层除返回文章详细内容外也会调用计数器服务给对应文章加阅读数。顾客进行点赞、收藏、评论这些互动行为时，请求会对应发送到点赞控制层、收藏控制层、评论控制层，各自对应调用自己的服务来给点赞表、收藏表、评论表进行数据添加以及更新文章表的相关统计字段。查看附近信息时序图如图5-37所示。
图5-37查看周边资讯时序图
这是一个简易的信息浏览和互动社区界面设计。页面结构类似于新闻软件。上方为信息类别导航栏，中部为信息流，每一条信息都以图文结合的摘要形式展现出来，有封面图、标题、部分内容展示、发布方及发布时间。每一个信息条目的底部锁定一排互动按键：一个心脏状的"赞"键，一个星星状的"收藏"键，一个气泡状的"评论"键，旁边显示当前数值。点击信息标题或其封面图片便会跳转到该信息的具体内容页面，详情页使用舒适的排版方式，文章下方为讨论区，可在此发表或查看别人留下的反馈意见。查看附近信息界面如下图5-38所示。
图5-38查看周边资讯界面
第六章 系统的测试
6.1 测试目的
系统测试旨在验证"同人周边订单管理系统"的各项功能是否符合需求规格说明书的定义，评估其在模拟真实环境下的运行稳定性与数据处理的准确性。核心目标包括确认不同角色用户的业务流程能够完整、正确地执行，例如从开团创建、审核、用户参团到订单发货的端到端流程；检验系统对异常操作和边界条件的容错能力，如输入非法数据、重复提交、权限越界访问等；保证关键数据在多层业务逻辑流转后的一致性，例如库存扣减与订单生成的同步、支付状态与订单状态的联动。通过系统的测试活动，旨在发现并修复潜在缺陷，提升软件质量，为系统最终上线提供可靠性保障。
6.2 测试方法
本次测试以使用黑盒测试的方式为主，关注的是系统的功能表现，不需要关心内部的代码结构和实现细节，根据系统的需求规格说明书以及设计方案，对每个业务模块的功能编写对应的测试用例。搭建独立的测试数据库、应用服务器和客户端浏览器，模仿真实的部署运行环境21。手工执行测试用例，分别扮演管理员、厂家用户、团长用户、普通用户等不同用户类型，在权限范围内执行一系列典型操作，查看系统实际返回的结果是否符合预期。实现了对主要业务流程例如开团审批流程、打样申请流程、参团采购流程、发货流程等等；用户界面元素是否可点击、交互响应是否即时等等这些功能点的考察。
6.3 测试用例
（1）开团信息审核功能测试如表6-1所示。
表6-1开团信息审核功能测试
| 测试项 | 测试步骤 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|
| 正常审核通过 | 1. 管理员登录系统。 2. 进入"开团信息管理"，找到状态为"待审核"的记录。 3. 点击"详情"查看完整信息。 4. 点击"审核"，选择"通过"，填写审核意见后提交。 | 1. 该条开团信息状态更新为"已通过"。 2. 团长用户收到审核通过的通知。 3. 该开团信息在前端商城对用户可见。 | 与预期结果一致 | 测试成功 |
| 审核驳回 | 1. 管理员登录系统。 2. 进入"开团信息管理"，找到状态为"待审核"的记录。 3. 点击"审核"，选择"不通过"，填写驳回原因后提交。 | 1. 该条开团信息状态更新为"未通过"。 2. 团长用户收到审核驳回的通知及原因。 3. 该开团信息在前端商城不可见。 | 与预期结果一致 | 测试成功 |
| 查看详情 | 管理员在列表页点击任意开团记录的"详情"按钮。 | 系统弹出或跳转到页面，显示该开团项目的全部详情，含图片文字等。 | 与预期结果一致 | 测试成功 |
（2）用户参团购买功能测试如表6-2所示。
表6-2用户参团购买功能测试
| 测试项 | 测试步骤 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|
| 正常参团下单 | 1. 普通用户登录系统。 2. 浏览开团信息，选择一个商品进入详情页。 3. 选择规格，输入购买数量，填写收货地址。 4. 确认订单信息，选择支付方式并完成支付。 | 1. 系统生成一条状态为"待发货"的参团购买记录。 2. 该开团的已参团人数相应增加。 3. 用户可在"我的参团"中查看到该订单。 | 与预期结果一致 | 测试成功 |
| 库存不足参团 | 模拟库存只有1件的即将售罄产品，两个客户同时对这个产品下了订单并进行了付款操作。 | 系统需要通过并发控制来保证仅有一个客户的订货能够成功，而另外一个客户在进行支付的时候应该给出库存量不足或者订货失败的提示信息。 | 与预期结果一致 | 测试成功 |
| 查看订单详情 | 用户在"查看参团购买"列表中点击某条订单的"详情"。 | 系统显示该订单的所有信息，包含货物信息、送货地址、支付金额、发货情况等。 | 与预期结果一致 | 测试成功 |
（3）工厂打样对接功能测试如表6-3所示。
表6-3工厂打样对接功能测试
| 测试项 | 测试步骤 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|
| 工厂处理打样申请 | 1. 工厂用户登录系统。 2. 进入"工厂打样管理"，查看团长提交的申请。 3. 点击"详情"查看设计图稿和备注。 4. 进行审核操作。 | 厂方用户可查看申请信息，并可根据需要进行通过或者驳回操作，操作后申请状态相对应改变。 | 与预期结果一致 | 测试成功 |
| 团长提交打样申请 | 1. 团长用户登录系统。 2. 在工厂详情页点击"打样申请"。 3. 填写表单，上传设计图稿，提交申请。 | 1. 系统提示申请提交成功。 2. 团长申请记录及相应工厂的打样管理列表中显示此条待办记录。 | 与预期结果一致 | 测试成功 |
| 打样成果确认 | 1. 工厂完成打样后，在"打样对接管理"上传成品文件。 2. 团长用户在对接管理中查看成品并进行确认。 | 双方可以通过此模块进行成品文件传输以及确认状态更新，流程状态依据双方的操作正确流转。 | 与预期结果一致 | 测试成功 |