做微商城这个项目最怕的不是写不出代码而是项目做到一大半才发现需求理解错了、架构选型也不合适推倒重来的成本远比想象中高。这一章我准备完整拆解一个“微商城”前后台实战项目从需求分析到架构设计的全过程还原我在实际项目中是怎么收集需求、梳理业务规则、做用例建模、划分模块边界、设计数据库和接口契约的。内容适合刚入门的学生也适合要独立带小团队的初级工程师照着这个流程走能避开不少我当年踩过的坑。1. 为什么这个微商城项目值得把需求分析当回事1.1 越小的项目越容易死在需求不清上我见过太多团队做微商城上来就画页面、建表、写接口一周后UI做出来了产品经理说“我要的不是这个交互”运营说“优惠券的互斥规则漏了”老板说“后台连个销售报表都没有”。问题从来不在技术而在需求根本没有锁死。微商城听起来只是一个小电商系统真拆开看用户端、商家端、管理端三个方向订单、商品、支付、营销、库存、售后每一条线都藏着大量隐性规则。任何一个角落没定义清楚后期就是无休止的改动和扯皮。所以我在真正动手设计之前宁愿多花两三天把需求分析做扎实。不是说一定要写出几百页文档而是要把人、事、规则、边界全部对齐。需求分析的价值不是“写文档”这个动作本身而是逼着所有干系人在投入开发前把话讲清楚。1.2 微商城和普通电商网站相比差异在哪里很多人把微商城等同于“手机版淘宝”这个理解会直接带偏需求方向。我整理过微商城的核心特征主要有三点。第一前台要“轻”。用户端承载的核心动作就是浏览、加购、下单、支付、查订单、申请售后页面层级要浅操作路径要短不可能像PC官网那样堆大量营销模块。第二后台要“重”。微商城的运营管理能力才是项目价值的重心。商品批量上下架、库存调整、优惠券创建与发放、订单批量发货、售后审核这些功能的使用者是运营人员他们的操作习惯、权限边界、审核流程都必须单独设计。第三多端适配是硬约束。用户可能从微信浏览器、小程序、H5、App任意入口进来后台又可能是PC Web。需求分析阶段如果不定清楚“哪个端先做、哪个端只读、哪个端暂缓”架构设计时接口和页面都会很被动。1.3 需求分析阶段必须产出的几样东西我习惯把需求分析阶段的产出物固定成五件套需求规格说明书、用例模型、页面原型、非功能需求清单、技术约束说明。这五样东西不一定都要写成正式文档但内容必须齐全。需求规格说明书用来描述业务背景、角色、功能范围、核心流程和业务规则。用例模型把每个角色的关键操作抽象成用例并写清楚正常流程和异常分支。页面原型是需求的翻译器让非技术人员能直观确认自己看到的和想到的是不是一回事。非功能需求清单则要写清楚性能指标、并发预估、安全要求、数据保留策略。技术约束说明用来记录团队技术栈、部署环境、第三方服务等硬性限制这部分是需求分析和架构设计之间的桥梁。这五件套全部对齐之后架构设计才有依据。否则架构师只能拍脑袋定方案出了问题又说不清楚当初为什么这么设计。2. 需求收集与业务规则从“我要一个商城”到能落地的规格说明2.1 第一轮沟通画清角色地图与核心流程需求分析第一步不是写功能列表而是把“谁在用这个系统”和“他们在干什么”搞清楚。微商城项目里我一般先画出角色地图通常包含四类角色顾客、运营人员、商家/店主、系统管理员。顾客负责浏览购买运营人员负责商品、营销和订单处理商家有自己的商品和库存管理诉求系统管理员则管人员权限和全局配置。角色定下来之后接下来要梳理核心业务流程。我会让需求方从头到尾讲一遍业务怎么跑而不是逐个功能点去问。顾客侧的完整链路是浏览商品、加入购物车或直接购买、提交订单、支付、等待发货、确认收货、申请售后。后台侧的链路是商品上架、库存设置、营销配置、订单审核、发货、处理售后。把这两条主线画出来再往每个节点上挂细节点比零散地收集需求要高效得多。2.2 功能清单按前后台分流再按优先级排序角色和流程清晰之后功能清单就非常好整理了。我习惯把功能拆成前台用户端和后台管理端两大块然后按照“必须有、应该有、可以有”三个档次排优先级也就是常说的MoSCoW法则。前台用户端核心功能大概包括注册登录、商品分类浏览、商品详情、搜索、购物车、下单结算、在线支付、订单查询、取消订单、收货地址管理、优惠券领取与使用、售后申请。后台管理端包括商品管理、分类与品牌管理、库存管理、订单管理、售后审核、会员管理、优惠券与促销管理、内容管理、数据统计、管理员权限管理。这里要特别强调功能清单不等于需求规格。清单只能告诉你“系统里有什么”不能告诉你“这个功能在什么条件下怎么运作”。所以列完清单之后一定要逐个功能去过业务规则尤其是涉及钱、货、时间这三个维度的规则一处都不能含糊。2.3 最容易翻车的业务规则价格、库存、物流、售后我做需求分析时最怕听到“这个先不做后面再说”的规则因为后面往往再也没有机会说清楚。下面这几类规则我会在需求阶段反复跟业务方确认每一类都用具体例子逼他们表态。价格规则是重灾区。商品原价、销售价、会员价、促销价、优惠券抵扣这些价格同时存在时到底按什么顺序计算叠加还是互斥比如一个商品原价100元限时折扣价80元用户有一张满50减10的优惠券会员还能打95折最后该收多少钱我在项目里和业务方对过好几轮最终确定一套计算顺序先算商品级优惠再算订单级优惠最后算会员折扣并且明确规定同一层级优惠互斥。这个规则必须写进需求文档开发才有据可依。库存规则同样要盯死。用户下单时扣库存还是支付时扣库存下单后保留多长时间超时未支付是否释放库存不足时是禁止下单还是允许预下单这些选择直接决定订单表和库存表怎么设计也决定并发控制怎么写。我在项目里采用了下单锁库存、支付确认扣减、超时自动释放的方案后面数据库设计部分会详细展开。物流规则相对直观但也要提前定义。免邮门槛是多少不同地区是否差异化运费运费模板支持按件数和按金额哪种计费退款时运费退不退这些问题不澄清支付和售后流程都会产生歧义。售后规则是最容易在后期爆发冲突的。七天无理由退货谁来审核退款原路返回还是退到余额已发货订单申请退款是拦截快递还是收货后退款订单状态机里所有分支都必须覆盖售后的到来这是需求阶段绕不过去的一环。2.4 用一张表把非功能需求也钉死功能需求之外非功能需求也要在需求分析阶段写清楚。否则等系统上线被用户打爆才发现当初根本没约定性能指标。我一般用一张表格把这些内容固定下来例如预估日订单量、高峰并发数、支付超时时间、商品详情响应时间、后台操作的响应时间要求、运行环境、数据库要求等。每个项目指标不同但有一件事是一样的非功能需求必须有具体数字不能写“系统要响应快”这种话。响应快到底是1秒还是3秒并发50还是500处理方式完全不同。把数字定下来架构设计中的选型判断才有客观依据。3. 用例建模与原型确认让所有人先看见边界3.1 用例图不是画给老师看的很多人在学校做过用例图练习到了真实项目反而不愿意画觉得浪费时间。我的看法相反用例图恰恰是需求分析阶段性价比最高的产出物。它不涉及技术实现却能逼着你把所有参与者和用例之间的边界全部画出来。画用例图时我坚持两个原则。第一以业务主线为轴不要画成功能清单的图形版。比如“用户下单”是一个用例而不是“选择商品”“加入购物车”“填写地址”“点击支付”四个用例。用例讲究完整流程不是单次操作。第二参与者要精确到角色不要出现“用户”这种笼统概念。顾客、运营、系统管理员是三种参与者他们能触发的用例完全不同。用例图画完整个系统的边界也就浮出水面了。后期接口设计、权限设计、菜单设计都可以从用例图里找到依据它是一张可以一直用到开发阶段的地图。3.2 用例规约模板与“用户下单”示例用例图只解决“有哪些用例、谁参与”的问题用例内部的流程还需要用例规约来承载。我使用的模板通常包含以下字段用例名称、参与者、前置条件、主事件流、扩展事件流、后置条件、业务规则。拿“用户下单”这个用例举例写出来大概是这样的参与者是已登录顾客前置条件是商品有库存、用户有收货地址。主事件流包括用户选择商品并加入购物车、进入购物车结算、选择收货地址、确认订单信息、提交订单、完成支付。扩展事件流覆盖库存不足、地址缺失、支付超时、优惠券不可用等异常场景。后置条件是订单生成、状态为待发货。业务规则则写明价格计算顺序、库存锁定方式、优惠券使用限制。这样一份用例规约写下来开发不需要再追着产品问“这里到底怎么处理”测试也能直接从事件流里推导测试用例。用例规约在需求阶段花半天时间写省的是开发阶段好几天的反复沟通。3.3 原型是需求的“翻译器”核对清单要具体用例规约解决逻辑问题原型解决认知问题。需求方看文字描述容易脑补看到原型才知道“原来你说的是这样”。微商城项目里我优先做两类原型一类是用户端核心购物流程一类是后台管理端的关键操作页面。用户端重点是首页、商品列表、商品详情、购物车、结算页、订单列表、售后申请页后台重点是商品编辑、订单详情、售后审核、优惠券配置。原型用什么工具不重要重要的是核对动作。我每次交付原型都会附一份核对清单要求需求方逐项确认每个用例是否都有对应页面、每个页面上的按钮是否能在用例事件流中找到出处、异常分支在页面上有没有明确提示、不同角色看到的菜单和数据范围是否一致。这些核对项逐条打勾之后需求和开发之间才算真正同步了。4. 架构设计前后台开发的边界与分层逻辑4.1 前后台不是“用户端管理后台”这么简单需求阶段的前后台是按照角色划分的架构设计阶段却不能只按角色分成两个项目就完事。微商城项目在技术上至少要区分三个面面向顾客的商城门户、面向运营的商家运营后台、面向平台管理的系统管理端。这三个面可以有各自独立的前端工程但服务端可以共享核心业务模块。我见过一个典型的失败案例团队把后台管理做成一个独立服务用户端做成另一个独立服务结果商品、订单、库存相关代码在两边各写了一遍改一个字段要同步两个项目。正确做法是后端统一构建业务中台能力前端按角色构建不同入口。角色不同页面和接口范围不同但底层的商品、订单、库存、支付逻辑必须是同一套。4.2 单体优先的经典分层微商城这种规模的系统我的建议是最初采用单体架构按模块划分代码边界而不是直接上微服务。很多项目一上来就拆用户服务、订单服务、支付服务、商品服务看起来架构很先进实际上开发联调和部署成本都翻了好几倍而业务体量根本撑不起微服务的复杂度。单体架构内部依然要做分层Controller层负责参数接收和接口暴露Service层承载业务逻辑Dao层做数据访问外层再按业务模块划分包。用户、商品、订单、支付、营销、售后这些模块在单体里是逻辑隔离的模块之间通过Service接口交互不直接访问对方的数据表。这样设计后续真要拆微服务也能相对平滑地演进。4.3 前端工程结构设计与页面路由梳理前端架构同样需要提前规划。用户端推荐采用按业务模块组织目录的方式例如views下划分首页、商品、购物车、订单、支付、售后等模块每个模块内再细分页面组件和子组件。管理端则按平台后台和商家后台分开建工程避免两套菜单逻辑和权限逻辑混在一起。路由设计上用户端购物流程相关的页面要尽量控制在三到四层以内例如首页、商品详情、结算页、支付结果页。管理端则按菜单树组织一级菜单是商品、订单、营销、会员、统计、设置二级菜单是具体功能页。路由层级要和菜单权限联动后面做权限控制时才不会乱。4.4 微服务在这个项目里是备选项不是必选项我不反对微服务但反对在微商城这个体量上把微服务当作默认方案。判断依据很简单当前团队规模、业务预期、运维能力。如果整个项目只有三五个后端开发单体架构明显更高效。如果公司同时运营多个业务域需要独立扩展订单或商品服务那再考虑将核心模块拆出来并且要做好服务治理、链路追踪、分布式事务的配套准备。架构设计不是炫技是权衡。在一个团队能驾驭的前提下做到清晰、易维护、可扩展比堆一堆时髦名词有价值得多。5. 数据库模型与关键状态设计订单状态机是核心5.1 核心表清单与字段要点架构设计落到数据库层微商城核心表大概包括这些用户表、商品表、商品SKU表、购物车表、订单表、订单明细表、支付流水表、优惠券表、用户优惠券表、库存表、售后申请表、操作日志表。其中最容易设计失误的是SKU表。商品是SPU概念SKU才是具体可销售的规格组合。商品名称、主图、详情挂在SPU表价格、库存、规格属性挂在SKU表。订单明细记录下单时的SKU快照包含商品名、规格、单价、优惠分摊、实付金额。这些字段必须冗余保存因为商品信息后续可能修改而订单历史必须定格在下单那一刻。订单表的关键字段包括订单号、用户ID、订单状态、商品总金额、运费、优惠金额、实付金额、支付时间、发货时间、收货时间、关闭时间、收货地址快照。订单号我建议用业务单号规则生成例如日期加随机序列方便日志追踪和人工排查。5.2 订单状态机设计订单状态是整个微商城系统的核心枢纽状态设计不清楚支付、发货、售后全部会乱套。我最常用的订单状态集合如下待付款、已付款待发货、已发货待收货、已完成、已取消、已退款。每个状态之间的流转必须约束清楚不能出现跳跃。待付款可以流转到已付款或已取消具体取决于用户是否在有效期内完成支付以及是否主动取消。已付款待发货只能流转到已发货后台发货后进入待收货。已发货待收货可以流转到已完成用户确认收货后自动或手动完成。已取消和已退款是终态任何商业操作都不应该从终态再拉回到活跃状态。售后状态要独立设计。申请售后、售后通过、退款中、退款完成、售后关闭这条状态线和订单状态线联动但不能混在一起。订单是否允许发起售后取决于订单状态是否已达到已完成且未超过售后时效。这些规则都需要在需求阶段和业务方确认清楚。5.3 库存扣减超卖问题要从设计上堵住库存设计直接关系到超卖和资金安全。我在微商城项目里采用的方案是下单锁定库存、支付扣减库存、超时释放库存。理解起来很简单用户提交订单时把SKU库存表中的锁定库存加一同时可售库存减一但此时还没有真正扣减用户完成支付后锁定库存转为实际扣减用户超时未支付订单取消锁定库存释放回可售库存。这个方案落到数据库上我强烈推荐在库存表加一个可售库存和锁定库存两个字段扣减语句写成原子操作例如在可售库存大于等于待购数量的条件下执行更新。不要先去查询库存数量再在应用层判断并发场景下一定会出问题。分布式锁是兜底方案但数据库层面的条件更新是最简单有效的第一道防线。高并发场景下还可以考虑Redis预扣减再异步同步到数据库不过微商城初版一般用不到这个复杂度。5.4 价格与优惠的存储策略价格和优惠的存储规则核心原则是“订单表存快照规则表存配置”。下单时把商品名称、单价、折扣金额、优惠券信息、实付金额全部写入订单和订单明细后续营销活动怎么改都不影响历史订单的数据准确性。这个设计看起来简单但很多初版项目都会犯只存总价不存明细的错误导致售后对账时根本说不清钱是怎么算出来的。营销规则放在独立配置表中例如优惠券表、促销活动表。优惠券要区分创建主体、适用商品范围、使用门槛、有效期、是否与其他优惠叠加。数据库只负责存储计算逻辑放在Service层。如果价格计算规则将来变得复杂再考虑引入规则引擎初版用代码硬编码一套清晰的判断流程就够了。6. 接口契约与前后端协作不给前端挖坑的响应设计6.1 接口风格与URL规划接口设计是需求分析到架构设计最终落地的关键一环。微商城后端接口我倾向于采用RESTful风格资源用名词复数表达例如商品列表接口是GET /products创建订单是POST /orders支付是POST /orders/{id}/pay。动作接口要放在订单资源下作为子操作不要到处使用动词发散的URL。前后台接口要分开规划。用户端接口路径以/portal开头后台管理接口以/admin开头同时明确哪些接口是用户端可匿名访问的比如商品列表和详情哪些必须登录比如购物车和订单哪些是后台需要管理员权限的比如商品上下架和订单发货。接口权限清单要在设计阶段就输出开发才不会出现越权访问。6.2 统一返回结构与错误码表前后端协作最容易出现的分歧点是响应格式。我在项目里会在一开始就定死统一返回结构所有接口都返回一样的JSON格式包含成功标识、业务状态码、提示消息、数据负载四个字段。业务状态码不等于HTTP状态码业务失败也要返回HTTP 200由前端根据业务码判断逻辑。这样前端拦截器只需要处理一次默认逻辑异常提示风格也才能统一。错误码要分模块编段位。例如10000-19999是通用错误20000-29999是用户模块错误30000-39999是商品模块错误40000-49999是订单模块错误50000-59999是支付模块错误。每个错误码对应一条面向用户的提示信息和一条面向开发排查的日志信息。错误码表在接口设计阶段就要同步给前端让他们在代码里配置好映射而不是后端报什么前端就弹什么。6.3 幂等与防重订单支付这个环节必须处理幂等。用户点了支付按钮因为网络原因请求发送了两次如果后端不加控制就可能创建两笔支付单。我的方案是前端生成唯一请求号后端根据请求号做幂等校验同一个请求号只允许创建一笔支付单。支付回调同样要做幂等处理相同支付流水号重复回调时直接返回成功不再重复修改订单状态。防重之外还要考虑并发。用户同时对两个订单发起支付后端处理顺序不同可能导致库存和状态校验出现问题。支付模块的核心更新语句要保证原子性订单状态变更使用条件更新例如只在当前状态等于待付款时才允许更新为已付款。这样即使并发请求到达数据库层面也会把住最后一道关。6.4 接口文档与Mock联调接口文档我推荐使用Swagger或OpenAPI规范来维护定义好请求参数、响应示例、状态码说明之后后端可以直接生成接口文档前端也能在联调前看到完整的参数结构。接口定义越早冻结前端开发越主动。不要等后端写完了再补文档那是给自己挖坑。联调阶段配合一套Mock服务非常好用。前端在同一天依赖商品、订单、支付多个接口时后端进度不一致是常态。搭建一个简单的Mock服务按接口文档返回预设数据前端就能并行开发而不被阻塞。我建议把Mock数据写进接口文档的示例里一套数据前后端共用联调冲突会少很多。7. 需求分析到架构设计的落地自查清单7.1 动手写代码之前我会先过一遍七项检查设计文档写完不代表可以立即编码我习惯带着团队先过一遍自查清单确认没有明显漏洞。第一每个用例是否都能追溯到对应的页面、接口和数据表没有需求是“孤儿”。第二核心状态机是否覆盖所有异常分支尤其是支付超时、库存不足、售后申请这些边界场景。第三价格计算顺序是否形成文档并让前后端达成一致。第四库存扣减方案是否经过并发推演而不是只写了正常流程。第五接口权限是否细化到角色是否存在越权风险。第六非功能需求的数字指标是否有对应的技术方案支撑。第七第三方依赖如支付网关、短信服务是否已经确认环境可用。这份清单每次都能揪出几个问题。很多时候我以为是架构的问题查到最后发现是需求阶段模糊导致的模糊设计所以自查要由需求到设计逐层检查不要只盯着技术实现看。7.2 需求分析仿真实验里练的正是真实项目要的很多同学在实践教学平台上做过需求分析仿真实验会觉得那些用户故事、用例图、需求建模的练习离真实项目很远。实际上仿真实验要求的步骤和真实微商城项目走的路一模一样。差异只在于仿真实验给你的是已经整理好的场景而真实项目需要你从零散的业务描述里自己提取用户、流程和规则。我自己带项目时最深的感受是需求分析能力不是靠看理论文章提升的而是靠一轮轮真实对话逼出来的。你问业务方“这个优惠券能不能和满减叠加”问十次之后就知道业务规则该怎么整理你画过一次用例图发现开发完全不看下次就知道该把用例和接口路线画在同一张图上。所有这些能力都是在动手做项目的过程中逐渐内化的。7.3 一些关于架构设计取舍的个人体会架构设计阶段技术栈的选择应该以团队熟练度和业务需求为第一优先级流行度排第二。我见过团队为了用某个新框架把一个简单项目做得无比复杂最后维护的人苦不堪言。微商城这个项目用户端和后台采用前后端分离是合适的服务端先用单体分层、按模块划分边界是稳妥的数据库设计把订单状态机和库存方案做扎实是必须的。不要小看这一步一步的基础工作。需求分析做得透架构选型才不会迷路架构设计做得稳后面的编码、测试、部署才有依托。我做了这么多年项目越来越相信一句话项目中绝大多数严重事故都不是程序员代码写错而是需求和设计阶段早就埋下的雷。把前两步走扎实后面就是顺理成章的事。