02-逆向应用
逆向应用：模型 → 解构 → 具体
逆向应用回答「模型怎么用」。模型形成后，遇到新问题不再从零研究，而是用已有模型去识别、解构、映射。从成品反推模型有两种极端形态——复刻软件（产品层面反推设计）与逆向工程（二进制层面还原机制），本质都是「模型 → 解构 → 具体」。
一、模型形成以后，方向反过来正向建模之后，遇到新问题就是逆向：
12正向：具体事物 → 抽象 → 模型逆向：已有模型 → 解构 → 具体实现
以「循环」为例。已经懂了循环，遇到游戏问题「敌人不断生成直到玩家死亡」：
1234567已有模型：循环 ↓ 识别分析新问题 ↓ 发现「不断生成」符合循环结构选择 while / for ↓ 映射具体实现
不需要重新研究「什么是循环」——模型已经在手，要做的只是认出新问题里的模型结构，然后映射到具体。
二、逆向应用的三个步骤1234567已有模型 ↓ ① 识别：新问题里有哪个模型的影子候选模型 ↓ ② 解构：把新问题拆开，对照模型匹配 ↓ ③ 映射：用模型的具体形态实现具体实现
以「敌人不断生成」为例：
123① 识别：反复生 ...
01-正向建模
正向建模：具体 → 抽象 → 模型
正向建模回答「模型从哪里来」。第一次遇到一类问题时，我们不是直接拿到模型，而是先看到很多具体事物，观察、比较、提取共同结构，最后抽象成模型。这是所有知识的产生方式——循环、函数、分层、系统，都是从具体例子里长出来的。
一、模型不是凭空发明的教材常直接给出定义：「循环 = 对某个状态反复执行某种操作」。但第一次学习时，我们看到的不是定义，而是具体的东西：
1234例子 1：打印 1、2、3、4、5例子 2：遍历数组中的每个元素例子 3：不断读取用户输入，直到输入 q例子 4：游戏主循环（更新 → 碰撞检测 → 渲染 → 更新 → ...）
这些例子看起来完全不同。但观察久了会发现共同结构：
123456789具体程序 ↓重复行为 ↓循环结构 ↓for / while / loop ↓「循环」模型
模型是从具体例子里抽象出来的，不是先有定义再有例子。
二、正向建模的四个步骤12345678具体事物 ↓ ① 观察：看到了什么多个例子 ↓ ② 比较：有什么相同共同结构 ↓ ③ 抽象：把共同点提炼出来模型 ↓ ④ 命 ...
11-软件组织知识与四个层次
软件组织知识与四个层次——从功能设计上升到系统组织
为什么很少有人能讲清楚「软件系统到底是怎么构成的」？因为这套知识被分散在不同学科里：软件架构教怎么划分系统、操作系统教大型系统怎么运行、嵌入式教硬件如何逐层变成软件、框架设计教谁控制谁、Linux 内核教组装与注册。这一条线把这些拼成一个统一模型，并给出软件组织的四个层次：设计 / 组织 / 工程 / 系统运行。它是拆解与组织主题的收束——把前面所有线放回「软件组织知识」的全景里。
一、有教，但是分散在不同学科里之所以很少见到，是因为这里把几个通常被分散教授的知识领域，抽象成了一套统一模型。这串推导实际上跨了好几个领域：
1组件 → 接口 → 子系统 → 组装 → 框架 → 启动 → 运行时注册 → 调度 → 完整系统
大学教材通常不会把它们作为一门课这样串起来。
1. 软件架构：教「怎么划分系统」对应：模块、组件、接口、子系统、分层、依赖、组合。关键词：Software Architecture / Software Design（Component / Interface & ...
10-微服务与组装边界
微服务与组装边界——子系统提升为独立进程
微服务首先不是一种「代码分层」，而是把一个完整系统拆成多个独立运行的服务进程。每个微服务内部再进行自己的分层。这一条线回答：① 微服务到底是什么（不是多了一层，而是子系统提升到进程级）；② 为什么 Server 在 main、数据库不在（组装边界判断）；③ 真正的判断标准——不是「什么东西应该在 main？」，而是「这一层的组装边界在哪里？」。
一、微服务：子系统提升为独立进程微服务首先不是一种「代码分层」，而是把一个完整系统拆成多个独立运行的服务进程。每个微服务内部再进行自己的分层。
电商系统：
123456整个系统├── 用户微服务├── 商品微服务├── 订单微服务├── 支付微服务└── 库存微服务
每个微服务本身都是一个小系统123456Order Service├── Interface HTTP/REST / RPC├── Application OrderService（业务用例）├── Domain Order / OrderItem / OrderRule（业务模型和规则）├ ...
09-裸机hypervisor的系统组织
裸机 hypervisor 的系统组织——无 OS 时系统如何自组装
裸机 VT（Intel VT-x）程序没有 Linux 的 init、没有 RTOS 的调度器、没有 Qt 的事件循环——它必须自己建立整个系统：从硬件抽象接口开始，把 CPU/VMX/Memory/EPT/Interrupt/Communication/Hook 组织成子系统，再由 hypervisor_main() 完成初始化与组装。这一条线是「系统组织」最纯粹的案例：没有操作系统替你组装，一切组装责任都落在程序自己身上。同时它展示了两个重要方法：MVP 增量开发（先跑通最小闭环再逐步加子系统）与结构/流程/状态三维理解（只看目录看不到系统怎么运行）。
一、裸机 VT 程序本身就是一个小型系统先不要从「代码文件夹」开始，而是从系统职责开始。假设是 x86-64 Intel VT-x 裸机 hypervisor（EFI/bootloader 进入后自己建立 VMX 环境，最终启动 Windows/Linux gu ...
08-Linux的分层与组装
Linux 的分层与组装——三种组装方式与启动流程 vs 注册机制
Linux 不是简单的「应用层 / service 层 / 基础设施层」三层，而是一个巨大的操作系统系统集合：内核内部是很多子系统，每个子系统内部又有大量组件。Linux 也没有一个类似 Server.cpp 的「总组装文件」——它的组装分散在编译期组装、启动期初始化、运行时注册机制三种方式里。这一条线回答两个问题：① 一个超大型系统的分层与组装长什么样；② 启动流程（组装系统）与注册机制（运行时扩展）是两个完全不同的概念。
一、Linux 不是简单的三层12345678910111213Linux System├── User Applications├── System Libraries / APIs├── System Call Interface├── Kernel│ ├── Process / Scheduler│ ├── Memory│ ├── VFS / File System│ ├── Network│ ├── IPC│ ├── Security│ ...
07-嵌入式与单片机的分层
嵌入式与单片机的分层——硬件能力如何逐层变成应用能力
服务器、CLI、GUI 分层是从「代码职责」出发的；嵌入式程序多了一个根本性的东西——硬件。嵌入式最好不要直接套 Web 那套 Controller / Service / Infrastructure，更自然的是按 硬件 → 驱动 → 系统能力 → 应用 拆。这一条线是拆解与组织原则在嵌入式领域的完整案例：Driver 是接口，RTOS 是框架，Middleware 是子系统，Application 是功能——「分层」在这里不是目录层级，而是硬件能力如何逐层变成应用能力。
一、嵌入式软件的基本分层12345678910Embedded System├── Hardware├── BSP / Driver│ ├── GPIO / UART / SPI / I2C / CAN / ADC / PWM / Timer├── System / Runtime│ ├── RTOS / Task / Queue / Mutex / Timer / Memory├── Middleware / Protocol│ ├── TCP ...
06-模块-组织与复用
模块：组织与复用
在「系统→子系统→组件→模块→组装」的链条里，模块站在组织和复用的位置：组件实现职责（一个功能单元），模块把这些组件组织成一个完整功能，并让它可以被复用。这一条线讲两件事——模块怎么组织（数据+算法+接口的组合），模块怎么被复用（库、静态库、模板是复用的三种形态，各有边界）。「模块负责组织和复用」是拆解与组织主题下的一条独立线。
一、模块的双重身份拆解与组织的链条里，每一层各司其职：
123456789系统 ← 完整程序 ↓ 拆成子系统子系统 ← 一组相关功能 ↓ 由组件构成组件 ← 实现职责（一个功能单元） ↓ 负责组织和复用模块 ← 组织组件成完整功能 + 让功能可复用 ↓ 组装模块子系统 ← 组装回来
模块与组件的区别：
12345组件：数据 + 算法 + 接口（功能单元，实现职责）模块：把组件组织成一个完整功能，并负责它的复用组件回答「这个功能由什么实现」模块回答「这些实现怎么组合、怎么被复用」
所以模块站在链条的中间：向下组织组件，向上支撑复用。
二、组织：模块 &#x ...
05-只有组件的子系统如何被加载
只有组件的子系统如何被加载
拆解产生两类东西：已经是子系统（有生命周期、有框架），和只有组件、还没成子系统的东西。后者无法被直接调用——它必须在项目里被处理成可调用的形态：接口化，或框架化。接口化落在哪、框架化落在哪，不是固定的——由「这个组件是谁的」决定：业务组件接口化供调用层调用，库接口在基础设施层封装为原子化接口，全局工具（无论接口化还是框架化）放在 utils。「只有组件的子系统怎么变成可调用」是一条独立的线。
一、拆完不一定直接可用拆解产生的东西，并不都是「拿起来就能调」的。
12345已经是子系统：有生命周期，可被启动/停止 → LogSystem（start / stop / 队列 / 线程）只有组件：有数据、有算法、有原子接口，但没有生命周期、没有框架 → log 函数 + sink 组件 + 队列组件（零散的）
「只有组件」的意思是：
12✅ 有：数据结构、算法、原子化接口（组件 = 数据 + 算法 + 接口）❌ 没有：统一生命周期、初始化顺序、资源所有权
这样的东西没法直接被调用——调用者不知道「先初始化什么、谁拥有什么、用完怎么释放」。它必须先在项目里 ...
04-ECS与注册机制
ECS 与注册机制
03（游戏拆解与组装）已经给出了完整的非 ECS 拆解组装：Engine 负责怎么运行、Game 负责运行什么、GameApplication 组装。ECS 并不是另一种拆解，它只是在 03 的基础上增加了一个机制——注册机制：Engine 提供注册入口（registerComponent / addSystem），Game 把组件和系统注册进去，Engine 在运行时按注册内容调度。这一条线讲：注册机制是什么、它给拆解与组装增加了什么。
一、03 的组装是「写死」的03 的组装里，Game 把内容交给 Engine 的方式是直接调用：
12345678910class Game { void registerComponents(Engine& engine) { engine.ecs.registerComponent<Transform>(); engine.ecs.registerComponent<Health>(); } void r ...