DDD

流程是易变的、脆弱的，对象是稳定的、高内聚的。面向对象的流程是分治，将易变的流程拆分成多个稳定的对象，对象之间面向接口协作，复杂性拆分成局部复杂性。 现象 我们 iaas 很多代码都是面向过程，而架构上也有很多是面向过程，而没有面向对象。 比如创建主机，存储资源没有抽象，全都是在过程中各种条件判断来处理的。其实需要的是一个存储系统、存储对象。 创建备份也是一样，创建备份和存储备份耦合在一起，没有区分。 存储备份完全是面向过程，写了两个流程： rsync 上传到 snapshot； snapshot 之间复制副本。 其实创建备份和存储备份完全是独立的两个事务，而且是差别很大的两个事务。 很明显，存储应该是一个独立系统，是一个存储对象。 我们需要的是面向对象，过程应该是在对象内的。 核心：对象是骨架，流程是血肉 流程是易变的、脆弱的，编排流程； 对象是稳定的、高内聚的。 最终： 面向过程的流程，是一个大的、长的、前后依赖的、复杂性指数增加的判断组合； 面向对象的流程，是分治，将易变的、脆弱的，拆分成多个稳定的对象，对象之间面向接口协作，复杂性拆分成局部复杂性，在大流程里是一个线性复杂性，在对象内是常数复杂性。 相比面向过程的流程的指数复杂性，这是数学上可证明的面向对象的优势。 软件工程设计的目标就是 kiss，一切围绕控制复杂性设计。 宏观面向对象，微观面向流程 上层的业务流程确实是面向过程的，但它又不负责具体的业务规则，而是编排。 宏观架构上，要"面向对象"：划分好边界，把复杂的业务拆解成一个个职责明确、内聚的对象，以此来抗住需求的变更和系统的规模； 微观执行上，要"面向流程"：在 Service 层，清晰、直观地把这些对象串联成一条条业务流，满足用户的实际需求。 对象是骨架，流程是血肉。 面向过程 vs 面向对象 面向过程 优点：逻辑简单直接，符合人类"按步骤做事"的直觉；代码体积小、执行效率高；调试和上手成本低，适合小型程序； 缺点：可维护性差，需求变更时需修改大量相关函数，牵一发动全身；复用性低；扩展性差，难以应对复杂系统的需求迭代。 面向对象 优点：可维护性强，封装使对象内部变化不影响外部，模块化降低耦合；复用性高，继承和多态大幅减少重复代码；扩展性好，新增功能只需定义新类/方法，无需修改原有代码（开闭原则）；更贴合复杂问题的本质； 缺点：复杂度高，需设计类的结构、关系，上手门槛高；性能稍低；过度设计风险，简单问题可能被复杂化。 业务的悖论：用"空间对象"承载"时间流程" “业务的本质是流程（时间推进），但为什么现代软件工程推崇对象（空间治理）？” 这是软件设计中最迷人的核心矛盾。 我们通过 DDD（领域驱动设计）思想完成了这两者的空间与时间平衡： 宏观架构上（空间划分）——面向对象：划分出干净、内聚的领域模型（如用户、商品、订单）。这些对象是系统的"零件"，负责锁住状态与核心业务规则； 微观执行上（时间推进）——面向流程：在应用服务层，用直观的面向过程逻辑，将这些对象串联成一条条满足用户最终需求的"业务流"。 架构大智慧：对象是骨架（空间），流程是血肉（时间）。 好的代码，是用面向对象的画笔，画出面向过程的蓝图。 为什么业务是流，我们却要用对象？ 为了应对"变化"和"规模"。 如果一个业务流程永远不改，面向过程绝对是最高效的。但现实是，业务流程会无限膨胀和变化。 面向过程的灾难：假设一个"下单流程"，起初只有 3 步。随着业务发展，变成了 30 步，里面充斥着各种 if-else。最后这个流程长达几千行，没人敢改，因为改了第 5 步，可能会调断第 28 步的数据； 面向对象的解法：面向对象不是消灭流程，而是把流程中的"参与者（实体）“抽离出来，让它们自己负责自己的事情。下单流程不再是一条黑盒管道，而是变成了用户对象、商品对象、营销引擎对象、库存对象之间的交互。 用一个比喻来理解： 面向过程是"流水线工厂”：传送带上一条道走到黑，一旦产品要加个新功能，整条流水线可能都要停工重组； 面向对象是"现代企业组织"：划分为财务部、销售部、研发部。公司的业务依然是一个个流程，但流程是由各个部门通过协作完成的。如果财务流程变了，只需要财务部内部调整，销售部根本不需要知道。 小结 流程是易变的、脆弱的，对象是稳定的、高内聚的； 面向对象的流程是分治，复杂性拆分成局部复杂性； 面向过程的流程是指数复杂性，面向对象是线性复杂性； 宏观架构上要面向对象，微观执行上要面向流程； 对象是骨架，流程是血肉； 用面向对象的画笔，画出面向过程的蓝图。