传感器信号进了放大电路，下一步就该处理噪声和干扰了——这就轮到滤波器。这篇讲最简单也最常用的一阶 RC 滤波：低通（滤高频噪声）和高通（滤直流偏置），以及核心公式截止频率 fc = 1/(2πRC)。

文中的频率响应用 Python 数值仿真验证（7 项 PASS），不是纸面推导。

一、为什么需要滤波 ​

上篇《运算放大器入门》讲到 ADC 前置 = 放大 + 缓冲。但真实世界还有两个麻烦：

1. 高频噪声：电源纹波、电磁干扰、电

模拟信号经过滤波、放大，最终要变成 0 和 1 才能进计算机——而 0 和 1 的所有运算，底层都是逻辑门。这篇讲六大基本逻辑门、真值表、德摩根定律，以及它们和编程位运算的一一对应（你其实天天在用）。

文中真值表、德摩根定律、半加器用 Python 程序验证（9 项 PASS），不是纸面推导。

一、为什么程序员要懂逻辑门 ​

你可能天天写 a & b、a | b、a ^ b、~a——这就是位运算。而位运算在硬件上就是逻辑门：CPU 里几十亿个晶体管，组合起来就是一堆与门、或门、非门。搞懂逻辑门 = 搞

模拟电路把物理世界变成电信号，数字电路把它变成 0 和 1，接下来要运算、控制、通信——这就是嵌入式。这篇从全局讲嵌入式开发的整体轮廓：单片机 vs 嵌入式 Linux、STM32 是什么、开发流程、常见外设，以及为什么它和纯软件不一样。

一、嵌入式在解决什么问题 ​

普通软件跑在通用电脑上（CPU + 操作系统 + 无限内存）。嵌入式不一样：

• 专用：一个芯片只为特定任务（采集温度、控制电机、蓝牙通信）
• 资源受限：几 KB 到几 MB 内存、几十 MHz 主频
• 实时/硬实时：传感器中断来了必须立刻响应

Clean Architecture（整洁架构）是 Robert Martin（《代码整洁之道》作者）提出的，是《六边形与洋葱架构》的"系统化版本"。核心就一条依赖规则，但这条规则价值极高，面试也高频。这篇把它讲透：四层同心圆各是什么、依赖规则怎么落地。

一、解决什么问题 ​

和六边形/洋葱一样，Clean Architecture 解决的是"业务被开发框架绑架"的问题——业务代码里到处是 Spring 注解、MyBati

CQRS（Command Query Responsibility Segregation，命令查询职责分离）是《DDD 领域驱动设计》的常见搭档，核心思想一句话：把"读"和"写"拆成两个模型。这篇讲清它解决什么问题、怎么拆、以及它为什么常和 DDD、事件溯源一起出现。

一、解决什么问题：读和写"同床异梦" ​

传统做法里，读和写用同一个模型：

public class OrderService {
    // 写：创建订单，带一堆业

DDD（Domain-Driven Design，领域驱动设计）是复杂业务建模的方法论。传统三层架构（Controller/Service/Dao）在业务简单时够用，一旦业务复杂——规则多、状态多、对象关系复杂——就会露出"贫血模型"的问题。这篇把 DDD 的核心概念（实体/值对象/聚合/仓储）讲清楚，以及它和传统分层的本质区别。

一、解决什么问题：贫血模型的痛点 ​

传统三层里，实体常常是"贫血"的——只有 getter/setter，没有业务逻辑，逻辑全堆在 Service：

// 贫血模型：实体是"哑巴"，只有数据没有行为

事件溯源（Event Sourcing）是《CQRS》的常见搭档，核心思想一句话：不存"当前状态"，存"发生了什么"的事件序列，当前状态靠重放事件得到。这篇讲清它解决什么问题、怎么工作、以及它为什么和 CQRS 一起出现。

一、解决什么问题：当前状态"丢失了历史" ​

传统做法只存"当前状态"：

-- 订单表只存当前状态
UPDATE orders SET status = 'PAID' WHERE id = 123;

问题：

六边形架构（Hexagonal）和洋葱架构（Onion）是《分层架构》的进化，核心都是依赖倒置——解决"业务依赖数据库"这个老问题。这篇把两者讲清楚：它们怎么把依赖方向反过来、以及它俩的共同点和区别。

一、解决什么问题：业务被数据库绑架 ​

回顾分层架构的问题：

@Service
public class OrderService {
    private final OrderMapper orde

应用架构模式学习笔记——组织单个应用内部模块分层的模式，比设计模式（类级）宏观、比系统架构（分布式级）微观。点击下面的文章阅读：

UI 架构 ​

• MVC 模式——Model-View-Controller，最经典的分层，Spring MVC 的骨架
• MVP 模式——Model-View-Presenter，Presenter 替代 Con

分层架构（Layered Architecture）是所有架构模式的起点——Spring Boot 默认的三层（Controller/Service/Dao）就是它，六边形、洋葱、整洁架构也都是从它演化来的。这篇把它讲清楚：为什么要分层、分层的规则、以及它遗留了什么问题（这些问题正是后续架构要解决的）。

一、解决什么问题：代码没有结构 ​

不分层的系统，代码是"一坨"的：一个方法里，HTTP 请求处理、业务判断、SQL 执行全混在一起。结果是——改数据库要动到界面代码，改界面又担心碰坏业务逻辑，牵一发动全身。

分层架构的思路：**按"职