很多人一提领域驱动设计，就直接开始背实体、聚合和仓储这些术语，但真正重要的是先理解它为什么会出现。DDD 要解决的，是复杂业务下代码越来越像表结构搬运的问题。
先明确 DDD 不是一套固定分层模板
它更像一种建模方式，强调软件结构应该围绕业务概念来组织，而不是单纯围绕数据库表和通用 CRUD 去堆代码。
战略设计先解决边界问题
限界上下文、通用语言和上下文映射，核心都是在帮团队划清业务边界。边界不清时，再漂亮的代码结构也很容易失控。
战术设计才落到对象建模
实体、值对象、聚合、领域服务这些概念，是为了把业务规则收回模型内部。重点不在于名词背得多，而在于你是否知道规则应该放在哪里。
不是所有系统都要重度 DDD
业务足够简单时，过度建模反而会增加复杂度。DDD 更适合规则多、协作角色多、演化频繁的核心业务系统。
结论
理解领域驱动设计时，先想它要解决什么业务复杂度，再去看边界划分和模型设计，顺序比背术语更重要。
正文完
