01-从指令到业务系统
从指令到业务系统——软件组织的第一条演化线
从一条指令开始，经过结构化、函数、文件、分层，最终长成一个业务系统——由模块组成，每个模块 = 数据结构 + 算法 + 接口。这是所有软件的第一条演化路径。
一、从一条指令开始最开始，程序就是几条连续的指令：
123MOV EAX, 5 ; 把 5 放进寄存器ADD EAX, 3 ; EAX = EAX + 3MOV [addr], EAX ; 结果存进内存
CPU 按地址顺序取指令，一条执行完再执行下一条。没有分支、没有循环、没有函数。
二、第一次拐弯：判断与跳转要让程序根据情况选择不同处理，需要比较 + 条件跳转：
1234CMP EAX, 10JGE label_doneADD EAX, 1label_done:
程序第一次有了「逻辑」——根据输入/状态，走不同的路。这就是 if-else 的硬件本质。
三、重复与复用：循环和函数雏形循环 = 往回跳
1234567MOV ECX, 0loop_start:CMP ECX, 10JGE loop_end ...
08-领域模型
领域模型——正向从业务建模型，逆向从模型展开成流程
领域模型有两条方向：正向是从业务语言/现实问题分析出对象、属性、关系、规则与状态（把业务世界压缩成一个模型）；逆向是把已经建好的模型展开成开发流程——转成具体的步骤序列，每一步做什么、产出什么都有明确约定。正向回答「业务世界里有什么」，逆向回答「有了模型之后按什么顺序、一步步把它变成程序」。
一、正向：从业务语言到领域模型1.1 一个例子：图片管理器要做一个图片管理器，不能直接开始写界面。先问：这个软件操作的对象是什么？
123456Project 项目（一组图片的集合）Folder 文件夹（图片分组）ImageFile 图片文件ImageMetadata 图片元数据（尺寸/格式/拍摄时间）SearchQuery 搜索条件EditorDocument 编辑中的文档
这就是领域模型的第一步：识别领域对象。
再往下，对象有属性、有关系、有状态：
123456789Project ├── 属性：name, path, cover ├── 关系：包含多个 ...
07-游戏与建模的领域对象分析
游戏与建模的领域对象分析
游戏和建模（CAD/绘图/场景）的领域对象分析和一般软件是两条不同的线：一般软件的对象来自「用户要完成什么业务流程」，游戏/建模的对象来自「这个世界里有什么东西、什么规则」。分析游戏，就是在分析一个允许玩家行动的世界的结构；分析建模，就是在分析一个要被描述的场景的结构。
一、从一般软件到游戏：对象来源变了一般软件问：
12「用户要通过这个软件完成什么任务？」 → 对象：图片、订单、进程、项目
游戏问的是完全不同的问题：
12「这个世界里有什么东西？它们遵循什么规则？」 → 对象：玩家、敌人、道具、地形、关卡
以闯关游戏为例，领域对象不是从「用户任务」来的，而是从世界结构来的：
123456789101112Game├── Player 玩家（可控制的实体）├── Scene 场景│ ├── Background 背景│ ├── Terrain 地形│ ├── Obstacle 障碍│ └── Object 物体├── Enemy 敌人├─ ...
06-一般软件的领域对象分析
一般软件的领域对象分析
领域对象分析是建领域模型的第一步：从现实问题里把对象一个一个找出来。一般软件（GUI、服务器、工具类）找对象的方法有固定套路——从业务名词、用户操作目标、数据流里挖。这条线和「游戏/建模的领域对象分析」是两条不同的线：一般软件的对象来自业务流程，游戏的对象来自世界规则。
一、对象不是「想出来的」，是「分析出来的」新手做软件，常常直接从界面或类开始：
12❌ 先画界面 → 再补数据 → 对象随机出现❌ 先建类 → 类名凭感觉 → 对象和业务对不上
领域对象分析的正确顺序是从业务出发：
1234567业务问题 ↓ 分析业务名词（对象候选） ↓ 追问对象属性、关系、状态 ↓ 确认领域对象
对象不是发明的，是在业务里发现的——它本来就存在于问题描述里，只是需要分析动作把它挖出来。
二、三个分析来源1. 业务名词（最常用）业务描述里的名词就是对象候选：
12「用户可以创建项目，把图片按文件夹整理，搜索时按元数据过滤， 编辑后的图片可以保存回原文件」
1用户 / 项目 / 图片 / 文件夹 / 搜索 / 元数据 / 原文件
但名词要筛： ...
05-技术流
技术流：业务流每个步骤的「怎么做」链
业务流回答「做什么」——用户要完成的任务、程序要提供的能力；技术流回答「怎么做」——每个业务步骤在程序里如何实现。这一条线：把「怎么做」从一句笼统的话，展开成一条完整的决策链，并追踪它在五个演化阶段里的形态。
一、定义：做什么 vs 怎么做同一个业务步骤，有两个视角：
12业务流（做什么）：解析参数 → 格式化 → 返回结果技术流（怎么做）：怎么解析（strcmp？正则？）→ 怎么格式化（snprintf？流？）→ 怎么返回
业务流是用户视角：任务是「保存文件」，用户不关心用 fopen 还是 open。
技术流是实现视角：同一个「保存文件」，实现方式有无数种。
分层之前，二者常常被当成一回事——「保存文件」就是写那几行代码。分层之后，二者彻底分开：业务层写「做什么」，基础设施层写「怎么做」。
所以技术流的本质是：
每个业务步骤背后，都有一条「怎么做」的决策链。
二、技术流的展开：五个环节「怎么做」不是一步到位的，它层层深入：
123456业务步骤（做什么） ↓ ① 功能流程：程序内部怎么组织步骤（先做什么、后做什么、什么条件下做 ...
04-数据结构来自其他设计
数据结构来自其他设计：一条独立的设计来源
前三条线是功能分析链：需求 → 业务流程 → 功能点 → 功能流程 + 算法。数据结构不在这条链上——它不是从功能流程里分析出来的，而是来自另一条独立的设计链：领域对象分析 → 领域模型 → 数据结构。这一条线说明：数据结构为什么来自其他设计，以及那条独立设计链是什么。
一、功能分析链产生不了数据结构功能分析链的产物是「做什么、怎么执行」：
12需求 → 业务流程 → 功能点 → 功能流程 → 算法 做什么 怎么完成 提供什么 怎么执行 怎么计算
这条链上每一步回答的都是行为（做什么、怎么做），不是数据（有什么、怎么组织）。从头到尾走完这条链，得到的是一组功能和流程，而不是一份数据结构设计。
例如「结束进程」功能点，功能流程能推出「调用结束进程的接口」，但推不出「进程对象有哪些字段、进程列表用什么结构存」——后者来自对问题世界里事物本身的分析。
二、数据结构的真正来源：领域对象分析 → 领域模型数据结构来自对「问题世界里有什么」的分析：
1234567现实问题 ↓领域对象分析（问题世界里有哪些对象） ↓ ...
03-功能点到功能流程与算法设计
功能点 → 功能流程 + 算法设计：功能内部怎么执行
功能点回答「软件要提供什么能力」，功能流程回答「这个功能内部一步步怎么执行」，算法设计回答「每一步里具体的计算怎么做」。这一条线：分析功能点，得到功能流程和算法设计。它是四条分析链的第三条，也是最后把「业务」翻译成「程序执行」的一条。
一、功能流程：功能内部的执行步骤业务流程图是「用户视角」的流程，功能流程图是「程序视角」的流程——一个功能点内部，程序一步步做什么：
123功能点：读取进程内存 ↓ 功能流程（程序内部的执行步骤）ReadMemory → 检查参数 → 地址转换 → 调用驱动 → 返回数据
12业务流程图（用户视角）：查看进程 → 选择进程 → 打开 → 读取 → 显示功能流程图（程序视角）：检查句柄 → 地址校验 → 转换地址 → 读取 → 返回
业务流程描述用户的操作，功能流程描述程序的执行——同一件事的两个视角。
二、算法设计：功能流程里的计算功能流程的每一步，都可能需要具体的计算。算法就是这些计算：
123功能流程：ReadMemory → 检查参数 → 地址转换 → 调用驱动 → 返回数据 ...
02-业务流程到功能点
业务流程 → 功能点：软件要提供什么能力
业务流程描述「用户怎么完成任务」，功能点描述「软件需要提供什么能力来支撑这个流程」。这一条线：分析业务流程，得到功能点。它是四条分析链的第二条。
一、从流程到能力用户的任务不能由用户自己完成——要由软件提供能力来支撑。分析业务流程，就是要找出：每一步流程，软件需要提供什么能力。
123业务流程：查看进程 → 选择进程 → 打开进程 → 读取信息 → 显示 ↓ 每个环节都需要软件能力支撑功能：列出进程 / 打开进程 / 读取进程信息 / 显示信息
1234567流程步骤 需要的软件能力──────────────────────────────────查看进程 → 枚举进程列表选择进程 → 按 PID 定位进程打开进程 → 打开进程句柄读取信息 → 读取进程信息显示 → 输出格式化
功能不是凭空设计的——它从业务流程的每一步反推出来。
二、功能点：把功能拆到可设计的最小单元一个功能可能很粗（「管理进程」），需要继续拆成功能点：
12345功 ...
01-需求分析到业务流程
需求分析 → 业务流程：用户要完成什么任务
需求回答「用户要做什么」，业务流程回答「用户怎么一步步完成任务」。这一条线：分析需求，得到业务流程。它是四条分析链的第一条——之后才是「业务流程 → 功能点」和「功能点 → 功能流程 + 算法设计」，而数据结构来自另一条独立的设计链（见线 04）。
一、需求分析：从想法到需求点开发不是从「写代码」开始，而是从「想法」开始。想法先要被分析成需求：
1234567想法（模糊的、零散的） ↓问题分析（要解决什么问题） ↓需求分析（要做什么） ↓需求点（一条一条可追踪的需求）
例如「做一个进程管理器」：
1234想法：我想看看电脑里有哪些进程在跑问题：怎么查看、怎么结束不想要的进程需求：列出所有进程、查看进程详细信息、结束进程需求点：① 列出进程 ② 查看进程详情 ③ 结束进程
需求点的关键：每个需求点都能被追踪——后面设计的功能、写的代码、做的测试，都要能对应回某个需求点。这是工程控制线里「确保每个需求都有归宿」的分析侧版本。
二、业务流程：用户怎么完成任务需求点说「要做什么」，业务流程说「用户怎么一步步完成」：
123需求点：查看 ...
15-游戏领域的工程地图
游戏领域的工程地图——游戏是多工程组合体，还有普通软件没有的玩法工程与平衡工程一句话
游戏工程不是「游戏代码工程」，而是「创造游戏 / 实现游戏 / 理解游戏」三条线的组合体：创造游戏靠设计（玩法→规则→状态→事件→交互→反馈），实现游戏靠程序（逻辑/图形/音频/内容/工具/性能/测试），理解游戏靠逆向/调试/静态分析；此外游戏还有普通软件几乎没有的两层——把玩法本身做成工程的「玩法工程」，以及把数值做成反馈控制系统的「平衡工程」。
一、游戏工程的整体流程传统软件大致是：
1需求 → 设计 → 实现 → 测试 → 发布
游戏则更像：
12游戏目标 → 游戏概念 → 玩法设计 → 规则设计 → 世界/系统设计 → 交互设计→ 内容设计 → 技术设计 → 实现 → 调试 → 平衡 → 测试 → 打磨 → 发布 → 运营/迭代
最关键的是玩法和规则。例如闯关游戏的「玩家 → 移动 → 遇到敌人 → 攻击 → 敌人受伤 → 死亡 → 掉落 → 获得资源 → 下一关」实际上就是一个规则系统 ...