你有没有过这种体验一个看起来很小的case改起来却要牵扯十几个地方一张表的属性加了又加最后堆到两三百个字段人人都说要分层、要正交、要组合但真到动手时没人说得清一个case的属性到底应该怎么切分。我这里的case不单指switch case里那个分支也不单指测试用例里那条case而是一个更广义的东西一个具体的业务场景、一条业务规则、一份需要被处理的数据对象。它可以是一次新用户首单支付可以是高风险订单转人工复核这个规则也可以是一个订单、一次请求、一条审计记录。无论叫什么一个case都是由一堆属性组成的。而这些属性的组织方式决定了系统未来是越改越顺还是越改越乱。我这些年在订单、风控、数据平台项目里反复验证下来答案藏在这四个词里属性、分层、正交、组合。属性是素材分层是归类正交是解耦组合是装配。这篇文章就把这套方法完整讲一遍怎么用、为什么这么用、落到什么程度算到位。适合所有需要和case打交道的人——后端开发、测试、产品经理、数据分析师都适用。1. 先把case到底是什么盘清楚1.1 一个case在工程里的三种形态开头我先把口径统一一下。在工程实践里case这个词至少有三种常见形态SQL里的CASE WHEN表达式本质是条件分支根据属性的不同取值决定输出不同的结果。代码里的switch case本质是模式匹配根据某个判别属性的值选择不同的处理分支。业务里说的case本质是一组属性在特定取值下构成的一个状态空间。这三种形态有一个共性case 判别条件 结果路径。而判别条件就是由若干属性共同决定的。比如风控系统里有一个case叫高风险订单人工复核它的判别条件可能是订单金额大于5000用户历史退款率大于20%设备是新设备发货地与IP归属地不一致。当这些属性同时满足时系统就把这个case送入复核队列。所以你看业务case和switch case没有本质区别都是在属性上做判断和分流。理解了这一点后面所有内容才有意义——我们是在给判别条件和结果路径里的属性做工程化整理。1.2 属性满天飞的时候问题出在哪我见过最典型的反面教材一张订单扩展表从A列排到扩展列最后超过300个字段。研发每次查数据都要先翻字段字典新来的同事根本分不清哪些字段能用、哪些字段已经废弃。这个状态我叫它属性失控。属性失控有三个典型症状。第一属性之间互相纠缠。订单金额、实付金额、优惠金额、退款金额四个字段一会儿相等一会儿不等谁进前端展示、谁进对账口径全靠口口相传改一个字段另外三个跟着遭殃。第二属性没有稳定归宿。同一条数据A系统把它当状态存B系统把它当行为存C系统把它当策略配置存同一个case在五个系统里五种形态上下游对接全靠写胶水代码。第三属性无法被组合。新的case往往不是从零设计的而是老case换几个属性取值或者老case加几个属性模块但如果属性全揉在一起想只取其中一块拼装新case根本做不到只能复制粘贴再改造。这三个症状分别对应三件事没做好没分层、没正交、没组合。所以下面我按这个顺序逐个讲。1.3 分层、正交、组合是三个递进的动作我习惯把这三个词理解成三个递进的动作而不是三个并列的原则。先分层把case的属性按照职责和变更频率放到不同的层先解决属性归宿问题。再正交在每一层内部保证属性之间相互独立改A不影响B解决属性纠缠问题。最后组合通过基座属性加扩展属性块的方式把层内正交的零件拼装成具体case解决属性复用问题。一个很贴切的类比是搭乐高。一箱乐高零件混在一起很难搭要先按形状、功能分件这是分层乐高的拼插口标准化任意两个零件都能兼容这是正交最终按图纸把不同的件组合起来变成城堡、飞船这是组合。这个类比虽然简单但背后的逻辑是真的系统复杂度不是靠多写代码来克服而是靠把属性组织好来克服。2. 属性分层把case拆成几个稳定的层次2.1 我用得最顺的四层模型分层没有统一的银弹不同系统、不同团队完全可以有不同的分法。但我在大量项目里沉淀出一个四层模型用来覆盖90%的case都够用。这四层分别是身份层、状态层、行为层、策略层。理解这四层的关键不在于记住层名而在于明白每层要回答的业务问题是什么身份层回答这个case是谁的状态层回答它现在处在哪一步行为层回答它发生过什么策略层回答它该怎么被处理。这四个问题问完一个case的属性组织框架就立住了。身份层Identity描述这个case是谁的、属于谁。比如case_id、租户ID、用户ID、订单号、来源系统。这层属性几乎不变是case存在的锚点。状态层State描述这个case当前处于什么生命周期阶段比如待支付、已支付、已发货、已关闭。这层属性取值有限、可枚举通常对应一张状态机。行为层Behavior描述这个case发生过什么比如创建时间、操作人、审核记录、变更日志。这层属性是追加式的只记录事实不加工事实。策略层Policy描述这个case应该被怎么处理比如风控阈值、优惠折扣、规则版本、优先级。这层属性是决策参数最容易变最需要被独立管理。为什么要按这个顺序分因为稳定性递减身份层最稳定策略层最易变。分层的第一目的就是把易变和稳定分开。这样底层数据模型不会因为上层策略的变动而被迫迁移。我用一个订单case来示范。身份层是order_id、buyer_id、seller_id状态层是order_status、refund_status、payment_status行为层是created_at、paid_time、shipped_time、operator_log策略层是promotion_id、coupon_amount、shipping_policy。这样一分后续谁改策略、谁记日志、谁查状态边界都很清楚。2.2 遇到新属性用三个判据决定归哪层分层最常被问到的问题是这个属性到底该放哪层我给自己定了三个判据按优先级从高到低第一变更频率。写入后几乎不变的靠身份层生命周期内会被反复修改的靠状态层或策略层只追加不改的靠行为层。第二职责边界。描述性的靠身份/状态层过程性的靠行为层决策性的靠策略层。第三消费对象。主要被底层存储用、被业务计算用、还是被前端展示和外部系统对接用决定了它应该待在哪个接口契约里。我整理成一张对照表属性示例所属层级判断理由订单号身份层确定性锚点写入后不变支付时间行为层记录事实追加后不变订单状态状态层生命周期阶段枚举变化优惠策略版本策略层规则参数随业务频繁调整这张表看着简单但真实项目里难的不是对照表分类而是你愿不愿意花时间去做这个动作。很多人图省事把容易变的策略属性和稳定的身份属性混在一个对象里短期没问题半年后策略版本迭代起来牵一发动全身。2.3 三个最常见的分层错误我踩过三次坑写出来给大家避开。第一把展示属性塞进业务属性。按钮文案、字段排序、颜色标记这些是展示属性不是case的业务属性。一旦它们混进核心数据对象前端每次改样式都要动后端接口。正确做法是把展示属性做成独立的扩展块在组合阶段再接上去不进入核心层。第二把状态属性当成行为属性。有些人喜欢把状态历史全部写进一张日志表每次要看当前状态就从日志里现推性能和准确性都差。正确做法是当前状态放状态层历史流转放行为层两者分开存、分开用。状态层解决现在是什么行为层解决曾经发生过什么。第三把策略参数写死在业务逻辑里。阈值、开关、权重这些策略属性最容易散落在if-else里。正确的是放进策略层做成可配置项。很多配置中心本身也是按公共配置、服务配置、灰度配置来分层的这和case属性分层完全是同一个思想在不同维度上的体现。3. 属性正交让每一层内部尽量独立3.1 从施密特正交化看正交到底是什么意思正交这个词搞算法的人一听就懂做业务的人可能觉得有点虚。我借线性代数里的施密特正交化来把它说透。施密特正交化做的事情是给出一组不垂直的向量通过逐次投影和减法运算把它们变成一组两两垂直的向量。两两垂直意味着什么在一个坐标系里一个向量沿某个方向的分量发生变化时不会影响其他方向的分量。反过来如果两个向量方向接近那调整其中一个另一个方向的分量也会跟着变用工程设计的话说就是牵连修改。把这一点映射到属性设计上一组正交的属性就是你改其中一个属性的值时不需要连带修改任何其他属性。比如订单原始金额和折扣比例是接近正交的两个属性改折扣比例不影响原始金额而订单原始金额和实付金额如果不做计算拆分、而是直接互相套算那就不正交改一个必然要同步另一个。这里要强调一句正交不代表相互无关。折扣比例变了实付金额最终一定会变但那是组合计算阶段的事不是存储纠缠阶段的事。我们要做的是让属性在存储和定义上保持独立在计算时再按规则组合。这就是正交和组合的衔接点。3.2 让属性正交的四个具体动作只讲理念没有用我给出四个可以立刻执行的动作。这四件事分别消灭四种最常见的正交性破坏隐式依赖让两个字段互相绑架多份拷贝让同一事实散落四处裸操作让内部结构随时被外部改烂魔法值让枚举判断彻底失控。每一项都不难但坚持做下来属性之间的牵连会被压到最低。消除隐式依赖。如果一个属性可以由其他属性推算出来它就是派生属性。派生属性要么不存要么明确标注由某几个属性计算得到。允许既存源属性又存派生属性还要求两者永远保持一致是很多事故的源头。单一事实来源。同一个属性在一套系统里只能有一个权威定义。比如用户等级就存在用户服务里其他系统要用就实时查不要各自存一份用户等级快照否则必然口径冲突。接口契约化。层内属性不要被外部直接裸操作而是通过稳定的访问接口读写。比如行为层只提供appendLog不允许外部updateLog。这样内部属性怎么重构都不会影响外部调用方。枚举和字典规范化。不要把状态、类型这类属性散落成魔法字符串。比如认证状态就三种枚举值PENDING、APPROVED、REJECTED谁都不能在代码里硬编码出第四种。魔法值一旦蔓延正交性立刻崩塌。3.3 一次亲历的正交性破坏事故我讲一个自己踩过的真实事故。当时做一个风控审核系统订单表里同时存了原始金额、优惠金额、实付金额三个字段。听上去很正常对吧问题出在业务方要求优惠金额可以手工调整。于是运营每次改优惠金额系统都要写一段兼容逻辑去同步改实付金额。结果有一次并发场景下实付金额被两个任务同时改直接导致对账不平。排查到最后根因就是三个字段定义上不独立。实付金额被设计成数据库里的存储字段而它本质上是原始金额、优惠金额经过策略计算后的组合结果。它应该被组合计算出来而不应该当作正交属性来维护。后面修法很直白数据库只存原始金额和优惠金额实付金额在查询时实时计算如果一定要沉淀实付金额做对账就把它放进独立的对账扩展块由对账任务单独生成、单独校验不参与主流程的常规读写。这件事让我明白正交性不是洁癖而是让系统不被同步修改拖垮的保命设计。4. 属性组合用组合思维复用case4.1 组合优于继承case建模也不例外面向对象设计里有一条被反复验证的原则组合优于继承。在case建模里同样成立不要试图设计一个无所不包的超级大类让所有case都去继承它而要让每个case由基座属性 若干扩展属性块组合而成。组合数学里研究如何从集合中选取元素构成子集我们做case组合时也是在做类似的事只不过元素换成了属性块。继承的问题在于父类的每一次改动都会波及所有子类而且继承层级一旦超过两层该不该继承这个父类就变成了玄学。组合的问题在于它要求先有稳定的基座和边界清晰的模块否则组合本身也会散架。所以我们前面必须先完成分层和正交组合才会变成顺水推舟的事。以订单case为例。基座属性是order_id、customer_id、created_at、order_status它们像身份证一样任何一个订单case都必须具备。扩展块则有支付块pay_method、pay_time、transaction_id物流块logistics_company、tracking_no、shipped_time营销块promotion_id、coupon_id、discount_amount风控块risk_level、reviewer_id、review_result。一个正常订单等于基座加支付块加物流块一个预售订单等于基座加支付块可以没有物流块一个需要人工审核的风控订单等于基座加支付块加风控块。扩展块相对独立可以灵活拼接这就是组合的价值。4.2 组合三步曲基座、模块、装配规则组合具体怎么做我总结成三步先定基座再切模块最后写装配规则。第一步定基座。把所有case都必须有的属性收敛成基座属性数量控制在5到10个以内。基座一定要精简能不放就不放。多一两个字段都会让扩展块装配时瞻前顾后。第二步切模块。把剩余属性按业务域切成若干个扩展块每个扩展块自身内聚并且内部遵守正交原则。切模块的粒度以是否经常被独立复用为准支付信息是一块物流信息是一块营销信息是一块不要在模块内部再硬拆出半块。第三步写装配规则。明确在什么条件下装配哪些扩展块。装配规则不要散落在业务代码的if-else里最好做成一张配置表这样新增一种case时只需要新增一行配置而不是新增一份代码。这里贴一个我在实际项目中用过的配置示例{ case_type: risk_review_order, base: [order_id, customer_id, created_at, order_status], blocks: [payment, risk], conditions: [ amount 5000, refund_rate 0.2, device_is_new true ] }再配合一张case类型与扩展块的对照表case类型基座支付块物流块营销块风控块普通订单必选必选可选可选不选预售订单必选必选不选可选不选风险复核订单必选必选不选不选必选这张配置表一旦落地产品再提新case研发要做的事经常就只是新增一行配置。就算新增case需要新代码代码也只集中在那个装配器里不会散落到各个服务。4.3 组合结果的可观测性与存储落地组合不是把模块拼上去就完事还要让这个case到底由哪些块组成这件事可查、可审计。否则上线半年后面对一个case没人知道它当初带没带风控块、营销块是不是后来补的。我见过一种很稳妥的落地方式在case的元数据里存一份装配清单记录它由哪些属性块组成、每个块对应的数据源和版本。这个思路和HDF5这类数据格式的理念惊人地一致HDF5里一个数据集dataset是存储二进制大数据的本体元数据则作为属性附加在数据集上二者分离。翻译成业务语言就是数据本体是组合后的结果属性元数据是组合的说明书。先把说明书存好后面怎么拆、怎么验都有据可循。组合思想在代码结构上也有对应落地。现在很多Python后端项目把工程分成core、db、models、schemas、services几层本质上也是分层与组合models管模型定义schemas管输入输出校验db管持久化core管领域核心逻辑services管业务编排复杂对象靠组合结构来组织。分层和正交做得好这个装配过程会非常平滑。5. 一套可直接落地的case属性梳理模板5.1 从0到1的五个步骤我复盘过很多次自己的落地过程最终沉淀出五个步骤。拿到任何一个case都可以按这个流程走。第一步列出全量属性。先不要想分层把字段、概念、指标全部写出来。写不全没关系后面迭代补。第二步给每个属性打标签。按四层模型给属性归位归属不了的单独列进待定区。待定区是最重要的信号说明这个case的定义还没想清楚。第三步揪派生属性。凡是可以由其他属性计算得到的记录计算式并决定是否要存储。优先不存实在要存就放进专门的派生或汇总块。第四步查正交冲突。两两检查属性之间是否存在改一个必须改另一个的关系有就标注出来能拆则拆不能拆的就用计算式连接。第五步定组合规则。确定基座、切好扩展块、写装配规则。这一步完成后一个case的属性设计就算闭环了。这五步看起来简单但大多数团队正是因为跳过了其中某一步才在后期付出巨大的维护成本。尤其第二步里的待定区很多人都舍不得承认自己没想清楚硬把模糊属性塞进一个看似合理的层结果后面返工更痛。5.2 全景示例一个风控审核case的完整梳理我把上面的流程完整跑一遍用一个风控审核case做示例。初期全量属性可能会有case_id、用户ID、订单金额、优惠金额、实付金额、设备指纹、IP、下单时间、支付时间、命中规则ID列表、风险等级、审核人、审核时间、审核结论、复核状态、优先级、处理策略、通知状态、展示按钮文本……经过五步梳理之后收敛成这张表属性所属层次正交性说明组合规则case_id身份层唯一锚点不改基座用户ID、订单金额身份层描述主体不改基座设备指纹、IP身份层环境标识不改基座复核状态状态层状态机枚举基座下单/支付时间行为层追加式事实基座审核记录行为层只追加不改审核块风险等级策略层由规则实时计算风控块命中规则ID列表策略层独立配置项风控块处理策略策略层决策参数风控块通知状态状态层独立枚举通知块按钮文案展示属性不属于核心层展示块注意几个关键处理原始金额、优惠金额保留实付金额改成组合计算风险等级不再入库而是由风控块动态计算按钮文案被移出核心属性进入展示块。这样一个原本混乱的case就变成了一张清晰、可装配的属性清单。5.3 落地前必过的四道检查我把整套流程固化成一个检查清单每次设计完case过一遍这四问。第一还有没有属性无法归入某一个层如果有说明case的边界没有定义清楚或者认知不完整那就先别急着写代码去和业务人对齐定义。这个检查能暴露你最不愿意承认的问题这个case本身可能还没被想明白。第二有没有两个属性在描述同一个事实比如既存支付时间又存订单完成时间但含义重复这是冗余。冗余就是正交的敌人因为两个字段早晚会被改成不一致而你又说不清哪个才是对的。能合并的语义尽量合并不能合并的至少明确边界和计算关系。第三改一个属性会不会必须改另一个属性如果会要么合并成一个要么明确它们的计算关系绝不允许靠人肉同步。人肉同步一次性看着没事只要并发一上来必然出乱子。第四去掉某个扩展块基座是否仍然成立这个检查用来防止把本不该进基座的属性塞进基座。基座越干净组合灵活性越高。如果一个属性只服务于少数几个case它就不该待在基座里。这四问过完我对一个case的判断力基本就稳定了。这套清单我现在还在用就放在项目的文档里每次评审新case都要拿出来过一遍。6. 常见问题与排查实录6.1 属性越加越多怎么办这可能是最普遍的问题。属性变多本身不可怕可怕的是新增属性没有经过归类直接挂在大对象上。我的处理方法是每季度做一次属性盘点。盘点时只做三件事删掉废弃属性把新增属性归入正确的层发现某层膨胀到难以维护时强制切分成更细的扩展块。属性清单我维护在一个markdown文件里和代码一起走版本管理。这样任何一次属性变更都有记录不至于半年后没人说得清某个字段为什么存在。还有一个排查技巧如果发现有人频繁对同一个对象做宽泛的update说明这个对象的属性边界已经模糊了。正常情况下的update应该是小范围、按属性块进行的。如果一次update动了几十个字段那大概率是属性归类出了问题而不是单纯的代码写得快慢问题。6.2 正交了但组合不出来有朋友问过我属性已经拆得很干净但组合新case时还是要写一大堆胶水代码这正常吗我说不正常。这个症状的根因通常在装配规则缺失。装配规则必须外置不要把它写成散布在服务里的if-else而要收敛成一张配置表。这样组合一个新case只改配置不改代码就算改动复杂到必须写代码代码也只出现在一个装配器里其他地方全部读配置不会到处散落。我之前那套json配置落地后接新case的平均速度明显变快。原因很简单新增一个case时产品、研发、测试看的都是同一份配置逻辑透明、责任清晰。反而是那些不把规则放进配置、全靠代码分支处理的团队每次组合新case都像在做移植手术改一处崩一处。6.3 团队协作中的口径冲突最后一个常见坑是同一个属性名产品、研发、数据各有一套理解。比如订单金额业务上可能是含运费的总金额研发那边可能是不含优惠的原价数据报表用的可能是实付金额。这不是技术问题是口径问题。解法是建立属性字典。每个属性要有唯一标识、权威定义、所属层次、计算规则、责任人。属性字典不需要很复杂一张表或者一个文档都可以关键是要作为评审基础新增case时必须先查字典字典没有就先补字典再谈设计。我在实践里还会在属性字典里加一列归属服务指明这个属性的单一事实来源在哪里。这样不同团队对不上的时候不需要各自猜直接去归属服务核对就行。这个动作很轻但非常管用能省掉大量跨团队扯皮。我最早用这套方法是被一个订单系统逼出来的。那时候每天都有新的营销活动case要接属性越堆越多大家靠加班救火。后来我狠下心做了一次完整的属性梳理分层、正交、组合三步走完接新case的时间从几天缩到半天以内。这个结果不是因为我比谁聪明而是属性的组织方式对了系统的复杂度就不会失控。如果你手头正好有一个case要梳理不用等到系统乱了才动手从今天开始按这个流程走一遍很快就能感受到结构清晰带来的底气。case的属性没有标准答案但分层、正交、组合这三个动作是我在长期实操中验证过、永远不会过时的方法。