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

一、解决什么问题 ​

和六边形/洋葱一样，Clean Architecture 解决的是"业务被框架和数据库绑架"的问题。但 Robert Martin 把它提炼成了更明

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 执行全混在一起。结果是——改数据库要动到界面代码，改界面又担心碰坏业务逻辑，牵一发动全身。

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

MVC 是最经典、也是很多架构模式的源头——MVVM、MVI 都是它的"后代"，Spring MVC 更是 Java 后端的标配。平时写 Spring Boot 天天用，但 MVC 的"三部分职责、数据怎么流转、为什么后来又演化出 MVVM/MVI"一直没系统梳理过。这篇把 MVC 从头理清，作为架构模式系列的第一篇。

一、解决什么问题 ​

想象一个没有分层的小程序：界面渲染、用户交互、数据读写、业务逻辑，全写在一个类/一个文件里。结果是——改一处 UI 可能碰坏数据逻辑，改业务逻辑又担心影响展示，代码越堆越乱。

MVC 的核心思想一句

MVI 是 UI 架构演进的"终点站"之一，Jetpack Compose、Redux 都基于它的思想。它解决的是《MVVM 模式》遗留的"状态分散、数据流难追踪"问题。这篇把 MVI 的核心——单向数据流、不可变状态——讲清楚。

一、解决什么问题：MVVM 的状态分散 ​

MVVM 的双向绑定好用，但有个隐患：状态散落各处，数据流不透明。

• 一个界面可能有多个 LiveData、多个双向绑定
• 状态怎么变的、谁改的、什么时候改的

MVP 是《MVC 模式》到《MVVM 模式》之间的过渡形态，Android 早期开发几乎人手一个。它解决的是 MVC 里"Controller 和 View 耦合紧"的问题。这篇把它讲清楚：Presenter 和 Controller 到底差在哪、为什么它更解耦、又为什么后来被 MVVM 取代。

一、解决什么问题：MVC 的 Control ​