复杂业务逻辑从来不会自己变简单只会像藤蔓一样缠绕住每一个试图修改它的人。你接手一个看似寻常的订单模块却发现里面混合着优惠券抵扣、库存预占、发票开具、异步通知、审计日志以及十三个嵌套if-else。Java程序员对这种绝望并不陌生代码能跑但没人敢动没人敢改。问题往往不在于业务本身有多难而在于我们没有为复杂性构建合理的容器和通道。业务复杂是常态代码复杂却是选择。业务需要处理各种规则、状态、异常分支这是客观存在的复杂度而代码里那些互相纠缠的依赖、突破天际的方法长度、隐藏在角落的全局状态则是我们自己用懒惰和急躁堆出来的。优雅不是把代码写得多么精巧而是让每个复杂度都找到一个清晰的归属。当你看到一个方法有二十个参数一个类有三千行那不是业务复杂那是结构已经失控。从if-else的地狱里抬头绝大多数复杂度首先表现为疯狂的if-else。当你写下if (type 1) ... else if (type 2) ... else if (type 3)你其实是在用代码语言描述一张没有列出来的决策表。这种逻辑不是不能工作而是无法演进每加一个新类型就要找到所有相关的地方改条件。更危险的是多个条件的组合会形成指数级的路径测试根本覆盖不全。if-else的深层问题是把规则和流程焊死在了一起。规则应当是可被命名的、可单独测试的、可自由组合的流程应当只关心步骤先后。当你把规则抽出来用策略模式或枚举策略去承载if-else就会自然退化成一行查找。比如一个电商系统的优惠策略有新人价、会员价、秒杀价、组合折扣等。你用枚举实现Strategy接口每个枚举项都实现自己的calculate(Order order)。主流程只是拿到一个策略集合汇总结果。这样新增一种优惠策略就是新增一个枚举项而不是在所有订单逻辑里再打一个补丁。策略模式的价值不是消灭条件判断而是把条件判断收敛为一个显式的、可扩展的映射。当然不要滥用——如果策略只有两个且永远不会变那直接if更简洁。分层让每层只回答一个问题有了策略还需要有边界。很多人觉得三层架构是老掉牙的东西但在面对复杂业务时它依然是最可靠的骨架。分层的核心价值是限制了不同类型的代码可以互相接触的路径。Controller只做参数解析和协议转换它不应该知道数据库字段也不应该知道折扣怎么算。Service层做用例编排它调用领域对象和基础设施接口但自身不应该写复杂的策略规则。Repository只负责持久化它不应当包含业务判断。当你严格执行这种边界你会发现大多数乱其实来自于越界。一个典型的越界例子Controller里直接调用Repo获取数据然后循环算价格再塞进Map返回前端。这样做的直接后果是相同的逻辑在多个Controller里重复而且一旦规则变化你要在N处修改。优雅的做法是Controller问Service要一个订单页VMService会去Repo拿聚合根调用领域方法计算总价再装配成ViewModel。不要让Controller知道如何算只让它知道要什么。这个原则看似简单却足以让混乱的代码迅速归于秩序。让业务规则住在领域模型里贫血模型是Java后端最常见的坏味道。你的实体类里只有getter/setter所有业务逻辑全部堆在Service里。这很符合MVC的习惯但其实是在退化。业务规则应该尽量贴近它操作的数据这就是领域模型的含义。比如一个订单有取消操作取消是有前置条件的未支付才能取消已发货不能取消而且取消后要释放库存。这些规则应当写在Order对象自己的cancel()方法里而不是写在OrderService的某个方法中。这样所有调用方只能通过order.cancel()来取消订单规则不会绕过去。复杂业务中用值对象来表示无标识的量也极其有用。比如金额、电话号码、日期范围把它们封装成值对象就可以在内部保证不变量。一个Amount类可以阻止你写出double price然后直接比较浮点数的荒谬代码。值对象让类型系统变得有表达力——参数是Money而不是BigDecimal amount加一个注释。当业务的约束被编码进类型很多非法状态在编译期就被禁止了这比任何运行时防御都要优雅。状态机把状态变迁装进表格订单、审批、任务流转这类业务的核心是状态。状态越多分支越多代码越容易烂。用一堆布尔字段或字符串常量来表达状态是不能维护的。状态机提供了一种结构化方式明确状态明确事件明确转移条件明确转移动作。你可以用枚举实现一个轻量状态机每个状态有一个Mapkey是事件value是转移结果目标状态和可选的钩子动作。调用方只需问currentState.handle(event)而不是写那些if(status.equals(PAID) action.equals(REFUND))。这种设计有一个额外好处不可能的事件组合在编译期就被地图的查表逻辑排除在外运行时抛出的不再是为什么这里有脏分支而是明确指示当前状态不允许该事件。更重要的是状态机把状态流转的描述集中在一个类里审查者可以像读表格一样了解全部可能路径大大降低沟通成本。如果状态特别复杂还可以考虑引入Spring StateMachine这类框架但大多数场景下一个枚举状态机远远够了。函数式风格让数据流动起来复杂业务往往要经历一系列数据变换原始请求到DTO再聚合到领域对象再拆解成多个响应。如果每一步都靠for循环和中间变量代码会非常啰嗦而且中间状态难以追踪。函数式风格鼓励你把处理链路写成一组纯函数的组合让数据像流水一样经过每个节点。Java 8的Stream和Optional只是入口更深层的用法是组合Function类型。比如你可以定义一个PriceCalculator接口然后andThen接上税则、舍入、格式化或者用Function的compose把前置校验、权限过滤串起来。这样的代码有几点质变第一每个函数可以单独单元测试不需要构造整个执行环境第二函数不修改外部变量因此并发安全第三链条上的每一步都是显式的阅读者看代码就知道数据流怎么走。纯函数让人安心是因为它没有隐藏的时序依赖和共享状态。你可以放心地删除、调换、复用其中的任何一段而不必担心波及外部世界。当然Java的函数式接口语法还不够优雅但这不妨碍你用它组织内核把IO和副作用留在边缘。规则引擎当变化快于发版有些业务的规则复杂到令人发指而且业务人员自己都说不清。这种情况规则引擎可能是值得考虑的选项。规则引擎的核心思想是把业务规则从Java代码中剥离出来用配置化或DSL来描述并允许动态加载和修改。比如判断一笔贷款是否合规涉及几十条政策且政策每周都在变。如果写死在代码里每次调整都要发版代价太高。用规则引擎可以把规则配置在数据库或文件中业务人员甚至能看到规则逻辑。但规则引擎不是银弹。它引入了解释器、外部依赖和调试黑盒一旦规则数量失控性能瓶颈和排查困难都会出现。我的观点是只有当规则的变化频率明显高于系统发版频率或者规则需要由非开发人员维护时才值得引入规则引擎。如果你只是想在if/switch和策略模式之间偷懒规则引擎只会让事情更糟。记住消灭if-else并不是目的可维护的代码才是目的。事件驱动让副作用远离主流程下单之后要发邮件要扣库存要通知BI要更新客户忠诚度积分。这些副作用如果在同一个事务里同步执行不但拖慢响应而且任何一环失败都会把主流程拖下水。领域事件是解耦连续业务动作的有力工具。你可以在订单已支付后发布一个OrderPaidEvent然后由各个监听器分别处理邮件、库存、积分。主流程只需要负责完成核心的订单状态变更其余动作都是事后的响应。Spring的EventListener和TransactionalEventListener让事件机制像发一条消息一样简单。但请务必想清楚事务边界使用TransactionalEventListener(phase AFTER_COMMIT)时只有事务提交成功才会触发监听器避免发给用户一封邮件但订单实际失败的情况。事件虽好却需要配合成熟的异常处理策略否则监听器里的异常会变成新的定时炸弹。异步监听时消息可能丢失同步监听时异常可能回滚主事务。把这些问题事先约定好事件驱动才能真正为你服务。事务与异常不要让错误纠缠复杂业务必然涉及多步写操作事务边界该怎么划往往比用什么模式更考验架构功力。事务不是越宽越好太长的事务会锁住数据库资源降低并发吞吐太短又可能破坏业务一致性。一个实用的准则是把事务边界放在用例入口附近但千万不要把异步副作用包进同一个事务。领域事件里的监听器要么用REQUIRES_NEW做独立事务要么异步执行并记录补偿日志。异常处理也经常被无限放大。最不优雅的写法是每个方法都捕获异常并打印一行堆栈然后返回一个null。这样做的结果是错误被静默吞掉调用方无从判断最终在某个远方出现空指针。更好的做法是区分业务异常和技术异常业务异常如余额不足、状态不合法应当声明为检查型或自定义运行时异常在统一异常处理器中转换为带错误码的响应技术异常如数据库连接断开则应当尽早抛出并保留完整的上下文。让异常沿着调用链传播到有决策能力的地方而不是在每一层都断案。测试复杂逻辑是设计的最严格裁判代码写得好不好不是看注释多不多而是看测试好不好写。如果一段复杂逻辑的单元测试需要mock五个对象、准备七组数据、还要模拟全局静态方法那这个设计一定是不优雅的。测试会逼你破坏依赖、隔离副作用、明确输入输出。这正是重构的绝佳动力为了让逻辑可测试你会自然地想到参数对象、依赖注入、纯函数、命令模式。面对复杂业务推荐用行为驱动测试BDD的方式描述规则Given一个前提When执行一个动作Then断言结果和副作用。这样的测试同时充当了活的文档新人接手时能迅速理解业务规则。每个测试都应该能回答一个业务问题折扣怎么算状态为何迁移异常如何抛出当规则能以测试用例的形式被讨论和评审你会发现很多隐藏的歧义和矛盾而这正是复杂业务逻辑最大的风险所在。优雅的底线克制与简单当你掌握了上述所有武器最需要警惕的是过度设计。优雅不是把能用的模式全用上而是只使用正好能让代码清晰的那一个。如果一个策略接口只有一个实现那就不要用策略模式如果一个事件只有一处监听那就不必发布领域事件如果规则半年不变那规则引擎纯属自我感动。最好的设计是你在维护代码时会感叹这太直接了而不是这太巧妙了。Java的强类型和丰富生态给了我们许多选择但选择本身也会变成复杂度。在每一次编程决策中都应该问自己这笔业务逻辑到底属于谁它需要支持哪种变化当前最简洁的表达是什么想清楚这些复杂业务就会变成一张清晰的地图而不是一片迷宫。复杂业务逻辑不值得恐惧真正值得恐惧的是我们甘心让代码投降于混乱。用结构去收纳规则用类型去表达约束用测试去守护行为用克制去拒绝浮华——这才是Java工程师应有的优雅。
