mimo code是一种轻量级设计共识，通过语义契约、状态机驱动、动词+名词服务单元和领域事件协作四大原则，实现复杂业务中可维护、可演进的一致性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在复杂业务逻辑中保持代码一致性，关键不是追求绝对统一，而是建立可识别、可维护、可演进的模式约束。MiMo Code（Minimal & Modular）不是一套强制规范，而是一种轻量级设计共识：用最小必要抽象封装变化点，以模块化边界隔离关注点。
用“语义契约”替代硬编码规则
当多个模块需协同处理同一类业务（如订单状态流转、审批层级判定），避免各自实现相似判断逻辑。定义清晰的语义接口，比如 OrderStatus.canTransitionTo(next) 或 ApprovalRule.match(context)，把规则判定收口到单一模块。外部只关心“能不能做”，不关心“怎么判断”。规则变更时，只需更新契约实现，无需散改多处 if-else。
- 契约方法返回明确语义结果（true/false、Result
、枚举状态），不暴露内部条件细节 - 规则数据（如状态图、审批矩阵）尽量外置为配置或策略表，代码只负责解释执行
- 单元测试覆盖契约行为，而非具体分支路径——重点验证“在A状态下是否允许进入B”
状态机驱动核心流程，而非条件跳转
业务主干逻辑（如订单履约、工单生命周期）一旦出现三层以上嵌套 if/switch 或状态交叉依赖，就该引入显式状态机。不是用框架堆砌，而是用结构化数据表达状态、事件、迁移与副作用。状态迁移函数本身无副作用，副作用（如发消息、调库存）由独立处理器响应事件触发。
- 状态定义为枚举或不可变对象，迁移逻辑集中于一个 StateMachine.transition(current, event)
- 每个状态对应一组合法事件，非法事件直接拒绝，不静默吞掉或抛泛型异常
- 日志记录每次迁移的 from/to/event/reason，便于追溯“为什么走到这一步”
领域操作封装为“动词+名词”服务单元
避免写 OrderService.process() 这类模糊入口。按真实业务动作命名服务，如 CancelOrderHandler、AllocateInventoryCommand、RevertPaymentAction。每个单元职责单一、输入明确、失败可逆、副作用可控。
- 输入参数是扁平 DTO 或值对象，不传 Entity 或上下文容器
- 执行前校验前置条件（如库存是否充足），失败立即返回结构化错误，不靠 try-catch 捕获业务异常
- 成功后返回结果对象（含新状态、生成ID、待通知事件列表），不修改入参或全局状态
跨模块协作靠事件，不靠调用链
当 A 模块完成动作需触发 B 模块行为（如支付成功后通知物流），禁止 A 直接调用 B 的 Service 方法。改为 A 发布领域事件（如 PaymentCompleted），B 订阅并处理。事件内容只含必要上下文，不含处理逻辑。
- 事件命名体现已完成事实（Past Tense），如 OrderShipped，而非 ShipOrderRequest
- 订阅者内聚处理自身职责，不反向调用发布者，也不协调其他订阅者
- 事件总线支持至少一次投递，关键事件加幂等键（如 order_id + event_type）防重
