前言

在传统 Spring Boot 项目开发中，我们习以为常的"Controller-Service-DAO"三层架构，往往会让代码逐渐演变成所谓的"贫血模型"。数据对象只有 getter/setter，业务逻辑散落在各个 Service 类中，随着系统复杂度增加，代码变得越来越难以维护。

领域驱动设计（Domain-Driven Design，简称 DDD）由 Eric Evans 在 2003 年提出，提供了一套应对复杂业务系统的建模方法论。本文将带你从实际项目出发，深入理解 DDD 的核心概念，并通过实战案例将 DDD 落地到你的项目中。

前言

"微服务"这三个字在技术圈已经热了十多年，但"怎么拆"始终是最困扰架构师的问题。拆得太粗——换了个壳的单体；拆得太细——运维成本爆炸，调试像噩梦。

本文不讲微服务的基础概念（假设你已经知道什么是微服务），聚焦于一个核心问题：面对一个单体系统，你该用什么原则来划边界？

---

第一部分：单体架构的痛点与拆分的时机

1.1 单体不是原罪

在谈拆分之前，必须明确一个观点：单体架构不是原罪。很多成功的系统——包括 GitHub 早期、Stack Overflow——都是单体架构。单体的问题不在于"它是单体"，而在于"它何时变得不可维护"。