ityqing的博客

本文阐述了基础设施层在DDD架构中的核心职责，重点分析了仓储模式的实现方式及其与DAO的区别。文章指出基础设施层负责所有技术细节的实现，包括对外部资源的适配（如数据库、消息队列等），而领域层和应用层仅依赖抽象接口。仓储作为聚合根的持久化抽象，提供集合语义的操作接口，与DAO在关注点、操作方式等方面存在显著差异。文中还提供了Spring Boot下仓储+MyBatis的完整实现示例，展示了PO与领域对象的转换过程，并强调了DDD中对象分层的重要性（PO/DO/DTO）。通过依赖倒置原则，实现了技术细节与业务逻

领域事件实现模式解析 本文系统介绍了领域事件（Domain Event）的概念与分层实现方案，通过代码示例展示了从领域层到基础设施层的完整事件处理流程： 领域事件定义 - 在领域层创建不可变的事件类（如OrderPlacedEvent），继承自基类DomainEvent，包含业务事实的核心数据。 事件收集机制 - 聚合根在执行业务逻辑时生成事件并暂存于内存列表（如Order聚合的place()方法），通过getDomainEvents()对外提供访问。 分层处理架构： 应用层：负责事务提交后的事件发布，使用

应用服务只负责"将订单和优惠券传给领域服务，拿到最终价格"。判断依据：把"规则"和"步骤"剥离——领域服务拿到已加载的聚合对象，只负责业务判断；这是 DDD 落地中最高频的困惑：同样是一段业务代码，到底该写在应用服务里，还是放进领域对象/领域服务中？：在应用服务中既写"加载 A 和 B"，又写"A 扣减、B 增加"的业务逻辑，把流程和规则混在一起。判断依据：条件的含义是"业务约束"，不是"流程控制"。判断依据：计算逻辑涉及多个领域对象，且规则本身具有业务含义（换了什么框架都不变），放领域服务。

DDD四层架构解析：领域驱动设计的核心分层与职责 摘要： 本文系统介绍了DDD（领域驱动设计）的四层架构体系，包括接口层、应用层、领域层和基础设施层。架构核心原则是依赖方向始终指向领域层，保持领域层作为系统最稳定核心。接口层负责协议适配，应用层专注用例编排，领域层封装所有业务规则，基础设施层处理技术实现。文章详细说明了各层职责边界、典型实现方式以及与MVC模式的对比，特别强调了领域层"不依赖框架"的设计原则，给出了依赖许可边界的明确标准。通过这种分层架构，DDD实现了业务逻辑与技术实现的解耦，使系统具备更好

横切关注点（Cross-cutting Concerns）是那些不属于单个业务用例、但需要在多处统一处理的逻辑，通常通过拦截器、过滤器或 AOP 实现，统一放在接口层。判断核心：接口层配置管的是"API 对外暴露的行为"（CORS、异常格式、文档）；基础设施层配置管的是"技术框架怎么运作"（连接池、序列化、调度器）。它本身不包含任何业务逻辑。）按照**“它在配置哪一层的技术基础设施”**来决定归属，而不是按照它使用了哪种注解。规则）、直接调用仓储、直接操作领域对象。

领域驱动设计中的实体与值对象 本文对比了MVC与DDD中实体和值对象的核心区别： 实体是具有唯一标识的领域对象，其身份(ID)在整个生命周期中保持不变，而状态可以变化。实体通过ID判断相等性，包含业务行为而非简单的数据容器。 值对象则通过属性值判断相等，是不可变对象。值对象描述"是什么"而非"是哪个"，任何修改都需要创建新实例而非改变现有对象。 关键差异： 实体关注身份标识(ID)，值对象关注属性值 实体可变，值对象不可变 实体包含业务行为，值对象主要承载数据 实体相等性基于ID，值对象相等性基于所有属性

本文介绍了限界上下文的概念及其识别方法，重点阐述了上下文映射模式及其实现。主要内容包括： 识别限界上下文的三种方法：事件风暴、术语冲突分析、组织结构分析（康威定律） 上下文内部的模型设计原则：保持概念精确独立，避免直接关联外部对象 六种上下文映射模式： 合作关系/共享内核（平等协作） 客户方-供应方/遵从者（上下游关系） 防腐层/开放主机服务（集成模式） 重点模式实现： 防腐层(ACL)通过适配器隔离外部模型 开放主机服务(OHS)提供标准化接口 发布-订阅模式通过领域事件解耦 代码示例展示了防腐层的典型实

本文介绍了领域驱动设计（DDD）中的核心概念与实践方法。主要内容包括：1）领域与子域划分，强调将业务划分为核心域、支撑域和通用域，重点投入核心域；2）通用语言的建立与应用，确保业务与开发使用统一术语；3）限界上下文的概念与实现，通过物理边界隔离不同业务模块；4）上下文映射模式，包括顺从者、防腐层和发布-订阅三种协作方式，推荐使用防腐层和发布-订阅实现低耦合。这些方法有助于构建清晰、可维护的复杂业务系统。

MVC 与 DDD 的核心思维差异 MVC 和 DDD 代表了两种截然不同的设计思维：MVC 关注技术分层，DDD 聚焦业务建模。 MVC 架构存在四大痛点：贫血模型导致业务逻辑分散、Service 层无限膨胀、技术与业务语言脱节、跨层依赖难以测试。其核心问题是业务逻辑被分散在各层，缺乏统一的领域模型。 DDD 通过战略设计（限界上下文、通用语言）和战术设计（实体、值对象、聚合）重构系统架构。与 MVC 按技术职责分层不同，DDD 采用四层架构（接口层、应用层、领域层、基础设施层），以领域层为核心，每个业务