书: https://pan.baidu.com/s/1XseSeFJwB_CgmZqmU5-_rQ?pwd=gb4u
笔记如下：
- “领域驱动设计（DDD）不是一种技术框架，而是一种以业务为核心的思维方式。”
- “通用语言（Ubiquitous Language）是连接业务专家与开发团队的桥梁，必须贯穿整个项目生命周期。”
- “限界上下文（Bounded Context）是DDD的战略核心，它定义了模型的边界和适用语境。”
- “领域模型不是数据库表的映射，而是业务概念的抽象表达和逻辑封装。”
- “实体（Entity）与值对象（Value Object）的根本区别在于是否通过唯一标识追踪生命周期。”
- “聚合根（Aggregate Root）是领域模型的一致性边界，外部只能通过根对象修改内部状态。”
- “领域服务（Domain Service）用于处理那些不适合放在实体或值对象中的业务逻辑。”
- “仓储（Repository）是领域模型的持久化抽象，其接口属于领域层，实现在基础设施层。”
- “CQRS模式将读写操作分离，通过不同的模型优化查询和命令场景。”
- “事件风暴（Event Storming）工作坊是快速建立领域模型的高效协作方法。”
- “领域事件（Domain Event）是记录业务状态变化的事实，也是微服务间通信的载体。”
- “六边形架构（Hexagonal Architecture）通过端口-适配器模式实现领域与技术实现的解耦。”
- “防腐层（Anti-Corruption Layer）保护核心领域不受外部系统劣质模型的污染。”
- “战术设计构建微观模型，战略设计规划宏观架构，二者必须相辅相成。”
- “领域模型的价值在于它能随着业务演化而持续适应，而不是追求初始设计的完美。”
- “DDD适用于业务复杂的系统，过度设计对简单CRUD项目反而是负担。”
- “领域层应该与技术框架（如Spring）保持独立，避免基础设施细节污染业务逻辑。”
- “事件溯源（Event Sourcing）通过持久化事件序列而非最终状态，实现业务过程的可追溯。”
- “DDD实施的成功标志是：当业务规则变化时，修改点能快速定位且影响范围可控。”
- “软件复杂性本质是认知负荷，DDD通过分治策略将复杂性封装在恰当的边界内。”