- 博客(222)
- 资源 (9)
- 收藏
- 关注
RSS订阅原创 DDD-033：案例：支付系统集成
本文介绍了支付系统的领域驱动设计(DDD)实践，主要内容包括： 支付系统核心业务场景分析：支付渠道对接、支付流程管理、退款处理和对账等关键业务功能 领域建模与聚合设计： 建立Payment聚合根，管理支付生命周期和状态机 包含Refund实体处理退款业务 通过防腐层隔离第三方支付网关 核心业务规则：防重复支付、金额校验、退款条件等5项关键业务约束 支付聚合的详细设计元素：支付ID、订单关联、金额、状态、渠道等核心属性 本文为支付系统提供了DDD设计的完整思路，适合需要实现复杂支付业务的开发者参考。
2026-06-24 20:31:19
435
原创 DDD-032：案例：库存管理系统实战
本文介绍了库存管理系统的DDD实战案例，重点分析了电商系统中库存管理的核心业务场景和领域建模方法。主要内容包括： 业务需求分析：涵盖入库管理、出库管理、库存调拨和预警等核心场景，以及5条关键业务规则（如库存不能为负、必须记录流水等） 领域建模设计： 采用Inventory聚合作为核心，管理单个SKU在仓库的库存状态 设计InventoryAllocation聚合处理预占库存 建立InventoryTransfer聚合管理仓库调拨 关键技术要点： 库存并发扣减处理 领域事件在库存同步中的应用 分布式一致性解决
2026-06-24 20:30:41
300
原创 DDD-031：案例：电商订单系统 DDD 建模
电商订单系统DDD建模案例摘要 本文通过电商订单系统案例，展示了DDD从需求到实现的完整过程。首先分析了订单生命周期状态机（待支付、已支付、已发货等）和核心业务规则。在领域建模阶段，识别出以Order为聚合根的订单聚合，包含OrderItem实体和ShippingAddress值对象，并通过ID引用客户、商品等其他聚合。案例重点探讨了订单状态机设计、聚合边界划分以及领域事件应用，为开发复杂业务系统提供了DDD实践参考。
2026-06-24 20:29:55
269
原创 DDD-030：DDD 落地常见问题与避坑指南
DDD 落地常见问题与避坑指南摘要 本章系统总结了DDD落地过程中的典型问题与解决方案。主要内容包括： 过度设计陷阱：避免在简单CRUD场景滥用DDD，应根据业务复杂度选择合适架构（三层架构/领域模型/完整DDD） 贫血模型问题：典型表现为仅有getter/setter的业务对象，正确做法是将业务逻辑封装到聚合内部形成充血模型 聚合设计问题：常见错误包括聚合过大（包含过多独立聚合）、聚合边界模糊等，应遵循单一职责原则设计聚合 其他常见问题：领域服务滥用、限界上下文划分不当、基础设施层污染领域层等 关键建议：
2026-06-24 20:29:19
118
原创 DDD-029：遗留系统重构为 DDD 架构
本文摘要（149字）： 本章系统探讨了将遗留系统重构为DDD架构的策略。首先分析了传统贫血模型系统的典型问题：业务逻辑分散、代码高耦合、状态管理混乱等。接着介绍了重构价值评估矩阵，从业务复杂度和变更频率两个维度判断重构优先级。核心重构策略包括使用绞杀者模式渐进替换旧系统，提取领域模型，以及数据库迁移方案。重点讲解了如何识别核心子域，逐步将业务逻辑从Service层迁移到领域模型中，最终实现从贫血模型到富领域模型的转变，提升系统的可维护性和扩展性。
2026-06-24 20:28:12
107
原创 DDD-028：DDD 中的测试策略
测试金字塔是 Mike Cohen 提出的测试策略模型，强调测试数量应该从底向上递减：单元测试最多、集成测试次之、端到端测试最少。测试金字塔：│ E2E 测试 │ ← 最少（执行慢、维护成本高）│ 10% ││ 集成测试 │ ← 适中（需要外部依赖）│ 20% ││ 单元测试 │ ← 最多（执行快、隔离性好）│ 70% │DDD 架构对应的测试分布：│ DDD 分层测试策略 ││ ││ │ 接口层（Interface Layer） │ │。
2026-06-24 20:27:07
156
原创 DDD-027：事件溯源（Event Sourcing）
事件溯源（Event Sourcing）是一种革命性的数据持久化范式，其核心思想是不存储对象的当前状态，而是存储导致当前状态的所有事件。通过记录业务操作产生的事件序列，可以重建任意时刻的系统状态。相比传统CRUD模式，事件溯源具有以下优势： 完整保留历史记录，支持状态重建和时间旅行查询 提供完整的审计日志，记录所有变更及其原因 业务规则集中体现在事件处理逻辑中 与CQRS架构天然契合，支持复杂查询需求 事件流可作为系统间集成的可靠数据源 实现事件溯源需要处理事件存储、聚合重建、快照机制等关键要素，适合需要完
2026-06-24 20:26:30
160
原创 DDD-026：CQRS（命令查询职责分离）
摘要 CQRS（命令查询职责分离）是一种将系统读写操作分离的架构模式，由Greg Young提出。核心思想是将改变状态的命令与读取状态的查询分离为不同模型，遵循"命令不返回数据，查询不改变状态"原则。 传统CRUD模式使用单一模型处理读写操作，导致以下问题： 模型职责冲突：写模型需要业务规则验证，读模型需要查询优化 性能权衡困难：写入需要规范化存储，读取需要反范式化 扩展性受限：难以同时满足读写扩展需求 CQRS解决方案： 分离命令和查询模型 可选用不同存储方案（写DB规范化，读DB反规范化） 避免复杂查询
2026-06-24 20:25:52
183
原创 DDD-025：API 设计与 Controller 层
DDD 架构中的 API 设计与 Controller 层实践 本文探讨了 DDD 架构中 Controller 层的设计原则与实践方法。重点阐述了： RESTful API 的核心设计哲学，包括资源为中心、统一接口、无状态等原则 常见 API 设计误区分析，如 RPC 风格混乱、HTTP 方法滥用等问题 符合 DDD 思想的解决方案，通过标准化的资源命名、HTTP 方法使用和响应格式 HTTP 方法的正确语义区分（GET/POST/PUT/DELETE）及其适用场景 文章通过对比传统 RPC 风格与 RE
2026-06-15 21:24:19
324
原创 DDD-024：事务管理与一致性保证
摘要 本章探讨DDD中的事务管理与一致性保证，强调"聚合即事务边界"的核心原则。事务的本质在DDD中被视为业务一致性边界，而非单纯技术实现。传统架构常出现的大事务问题（如跨聚合修改、事务范围过大）可通过单聚合事务原则和最小化事务范围解决。关键要点包括： 事务应仅修改单个聚合实例 避免在事务中执行远程调用、消息发送等非必要操作 使用领域事件实现跨聚合的最终一致性 事务设计需考虑并发控制和领域不变量维护 通过合理的事务边界设计，可在保证数据一致性的同时提升系统性能和可维护性，典型实现方式包括Spring的@Tr
2026-06-15 21:23:39
110
原创 DDD-023：MyBatis 与 DDD 的结合
本文探讨了MyBatis与领域驱动设计(DDD)的结合方式，分析了MyBatis与JPA的核心差异及各自的优劣势。文章指出传统MyBatis使用方式存在三个主要问题：Mapper接口直接暴露给应用层、PO对象承担双重角色、复杂查询逻辑分散。针对这些问题，提出了DDD推荐的架构方案，强调领域层与基础设施层的分离，保持领域模型的纯净性。最后给出了MyBatis在DDD架构中的正确使用模式，包括仓储接口设计、领域对象映射等核心内容，帮助开发者更好地将MyBatis应用于领域驱动设计架构中。
2026-06-15 21:23:03
127
原创 DDD-022：Spring Data JPA 与聚合持久化
本文探讨了Spring Data JPA与DDD聚合持久化的结合策略。核心观点是JPA与DDD存在设计理念冲突，传统JPA使用方式会导致领域对象与持久化对象混淆、聚合边界破坏等问题。DDD建议分离领域模型（充血模型）与持久化模型（JPA实体），通过转换层实现两者的映射。关键问题包括：类型暴露、业务语义缺失、双向关联暴露等，解决方案是建立清晰的领域层和基础设施层边界，保持领域对象的纯净性，避免JPA注解污染领域模型。
2026-06-15 21:22:28
171
原创 DDD-021：Spring Boot + DDD 项目结构
本文介绍了Spring Boot项目中基于DDD（领域驱动设计）的项目结构设计方法。主要内容包括： 传统技术分层结构的不足：业务边界模糊、修改范围大、领域模型弱化等问题 DDD项目结构的优势：按业务领域组织代码，提高可读性、降低重构成本、减少团队冲突 模块划分策略：根据团队规模和项目阶段，推荐渐进式模块化方案（单模块→模块化单体→微服务） 包结构设计原则：按领域分包、高内聚低耦合、依赖倒置，提供两种常见包结构示例 文章通过对比分析，展示了DDD项目结构如何更好地反映业务领域模型，支持团队协作和架构演进。
2026-06-15 21:20:45
370
原创 DDD-020：DTO、Assembler 与数据转换
DDD中的数据转换：DTO与Assembler 摘要 本文介绍了DDD分层架构中的数据转换概念，重点分析DTO(Data Transfer Object)和Assembler的设计与实现。主要内容包括： 数据转换必要性：不同层(UI层、应用层、领域层、基础设施层)需要不同的数据对象以避免安全风险、协议耦合等问题 DTO设计原则： 请求DTO包含输入验证规则 纯数据容器，支持序列化 与API契约对齐，按需裁剪字段 实践示例：展示了创建订单请求DTO的代码实现，包含嵌套结构和验证注解 转换价值：通过数据转换实现
2026-06-15 21:20:00
112
原创 DDD-019：基础设施层设计
DDD基础设施层是架构的最底层，为上层提供技术实现支撑。它包含四大核心组件：持久化层（实现Repository接口，处理数据存储）、消息传递层（事件发布与消费）、外部服务集成（第三方API调用）和技术工具（缓存、日志等）。基础设施层特点包括技术导向、依赖倒置（实现领域层接口）、可替换性和细节封装。其中Repository设计遵循接口与实现分离原则，领域层定义接口，基础设施层提供具体实现（如JPA、MyBatis等），实现技术细节与业务逻辑的解耦。
2026-06-08 21:36:35
355
原创 DDD-018：应用服务与事务脚本
本文摘要： 《应用服务与事务脚本》探讨了DDD架构中应用服务的设计模式及其与传统事务脚本的区别。应用服务是协调领域对象完成业务用例的薄层组件，负责事务管理、权限检查等，但不包含业务规则。与领域服务不同，应用服务位于应用层，协调多个领域对象交互。事务脚本则是过程化编程的产物，将所有业务逻辑集中在一个方法中，导致代码臃肿、维护困难。文中通过代码示例对比了两种模式的实现差异，强调应用服务模式更符合DDD分层架构原则，能更好地分离关注点。
2026-06-08 21:35:57
306
原创 DDD-017：六边形架构（Hexagonal Architecture）
六边形架构（Hexagonal Architecture）摘要 六边形架构（Hexagonal Architecture），又称端口与适配器架构，由Alistair Cockburn提出，核心思想是将应用程序分为内部核心业务逻辑和外部技术实现，通过端口和适配器交互。架构特点包括：内外分离（业务逻辑与技术实现解耦）、依赖倒置（外部依赖内部）、端口定义交互接口、适配器实现技术细节。架构分为应用核心（领域模型、应用服务、端口）和外围（适配器与基础设施），通过入站/出站端口与对应适配器连接外部系统。相比分层架构，六
2026-06-04 23:04:45
426
原创 DDD-016：分层架构与 DDD
DDD分层架构摘要 DDD分层架构在传统三层架构基础上，通过引入领域层解决核心业务逻辑分散问题： 架构分层： 用户界面层 → 应用层 → 领域层 → 基础设施层 各层严格单向依赖，领域层成为核心 关键改进： 领域层封装核心业务逻辑，实现富领域模型 应用层协调领域对象，不包含业务规则 基础设施层实现技术细节 优势： 业务逻辑内聚到领域对象 解耦技术实现与业务逻辑 提高代码可维护性和可测试性 实现要点： 实体/值对象包含行为 领域服务处理跨聚合逻辑 仓储接口定义在领域层 （96字）
2026-06-04 23:03:55
167
原创 DDD-015：领域事件（Domain Event
领域语言命名：使用业务术语，过去时态不可变性：事件一旦发生，内容不可更改事件溯源：存储事件流，可重建状态解耦聚合：聚合间通过事件通信可靠性保证：Outbox模式防止事件丢失。
2026-06-03 21:48:45
150
原创 DDD-014：工厂（Factory）
摘要 工厂（Factory）是DDD中封装复杂对象创建逻辑的模式，核心职责包括封装创建过程、保证对象有效性、表达创建意图和分离关注点。工厂适用于复杂对象创建场景，如聚合根的组装，通过静态工厂方法或独立工厂类实现。相比构造函数，工厂提供命名清晰、逻辑封装、返回灵活等优势。简单对象可直接使用构造函数，而涉及外部依赖或复杂逻辑时，应采用工厂模式。工厂应专注于创建职责，避免包含业务逻辑，确保领域模型的清晰边界。
2026-06-03 21:48:10
129
原创 DDD-013：仓储（Repository）
本文摘要： 仓储（Repository）是DDD中管理聚合持久化的关键机制，提供类似集合的接口访问领域对象。仓储区别于传统DAO的特点包括：面向聚合而非数据表、使用领域语言命名、隐藏数据访问细节。仓储的核心职责包括加载、保存、删除和查询聚合。文章通过代码对比展示了DAO与仓储的区别，强调仓储应返回领域对象并以聚合为单位操作。仓储接口设计应包含基础CRUD操作和领域特定查询方法，同时支持分页排序等需求。仓储实现应确保聚合的完整加载和保存，并处理领域事件的发布。
2026-06-03 21:47:31
128
原创 DDD-012：领域服务（Domain Service）
无状态：领域服务不持有业务数据，只有行为领域逻辑：包含真实的业务规则，而非简单转发使用场景：跨聚合逻辑、无归属逻辑、多对象协作、纯计算接口在领域层：定义体现业务契约区别于应用服务：领域服务做领域逻辑，应用服务做用例编排。
2026-06-02 22:02:00
210
原创 DDD-011：聚合与聚合根（Aggregate & Aggregate Root）
本文介绍了DDD中的聚合与聚合根概念。聚合是一组相关领域对象的集合，作为数据修改的单元，由聚合根和内部对象组成。传统开发中缺乏聚合概念会导致数据一致性风险、业务逻辑分散等问题。通过DDD聚合模式，可以封装业务逻辑，保证一致性，如订单聚合根负责维护订单项和总金额的业务规则。聚合的核心特征包括边界明确、事务一致性、唯一入口和不变量保护。文中通过代码示例对比了传统开发方式与DDD聚合模式的差异，展示了聚合如何解决业务逻辑分散和数据一致性问题。
2026-06-02 22:01:16
126
原创 DDD-010：值对象（Value Object）
值对象是领域驱动设计（DDD）中的核心概念，通过属性值而非身份标识来定义，具有无标识符、不可变性、值相等性和可替换性等特征。传统架构使用基本类型表示业务概念会导致类型不安全、验证逻辑分散等问题。通过值对象封装（如Money、Address等）可增强类型安全性，集中业务验证，并保证不可变性。值对象的核心优势包括线程安全、引用安全和语义清晰，其设计应遵循不可变原则，所有修改操作返回新实例而非改变内部状态。
2026-06-02 21:54:27
270
原创 DDD-009：实体（Entity）
摘要 本文介绍了DDD中的实体（Entity）概念，重点阐述了实体的核心特征：唯一标识符、可变性、生命周期和身份连续性。对比了传统贫血模型与DDD充血模型的差异，展示了充血模型如何将业务逻辑封装在实体内部，提高代码的封装性、可测试性和可维护性。文章还详细讨论了唯一标识符的重要性及其生成策略（如UUID和雪花算法），强调标识符应具备唯一性、不变性和可比较性等特征。通过代码示例，说明了如何实现一个符合DDD理念的充血模型实体。
2026-06-02 21:53:52
178
原创 DDD-008：DDD 与微服务架构
【原理】分布式单体（Distributed Monolith）：虽然拆分成了多个服务，但服务间紧密耦合，每次变更都需要修改多个服务，部署时需要协调多个服务。【历史架构问题】// ❌ 分布式单体的典型特征// 1. 跨服务的"大事务"@Service@Transactional // 这个事务根本不起作用！// 跨服务// 跨服务// 跨服务notificationService.sendSMS(userId, "订单创建成功");// 跨服务// 2. 服务间的循环依赖。
2026-06-02 21:52:59
193
原创 DDD-007：领域事件与事件风暴
摘要 本章深入探讨了领域驱动设计（DDD）中的领域事件与事件风暴方法。领域事件是领域内发生的具有业务意义的事实，其生命周期包括产生、存储、发布、订阅和处理五个阶段。传统同步调用方式存在强耦合、性能差等问题，而DDD通过事件驱动架构实现解耦，提升系统可靠性和可维护性。事件风暴作为战略设计工具，通过协作工作坊帮助团队快速建立领域模型。本章将指导如何设计领域事件、组织事件风暴工作坊，并将建模结果转化为限界上下文和代码实现，学习时长约90-120分钟。
2026-06-01 21:48:28
107
原创 DDD-006：上下文映射（Context Mapping）
本文摘要： 《DDD-006：上下文映射》章节深入讲解了领域驱动设计中的战略设计工具"上下文映射"。上下文映射用于描述限界上下文之间的集成关系和依赖关系，主要解决系统边界混乱、模型污染和团队协作问题。传统开发中常见的边界混乱问题会导致模块高度耦合、修改成本高昂，而上下文映射通过明确上下文边界、制定集成策略来规避这些问题。本章还介绍了上下文映射图的绘制方法、各种关系模式（如伙伴关系、客户-供应商关系等）、防腐层的实现技术，以及如何在微服务架构中应用上下文映射。学习目标是掌握上下文映射的核心概念、模式应用和防腐
2026-06-01 21:47:19
223
原创 DDD-005：限界上下文的识别与划分
文章摘要： 限界上下文（Bounded Context）是DDD的核心概念，用于划分业务边界，解决传统技术分层架构导致的业务耦合问题。识别限界上下文可通过事件风暴、名词分析或组织架构参考等方法，重点关注业务内聚性、变化频率和团队协作边界。以电商系统为例，订单、库存、支付等业务功能可划分为独立上下文，通过事件驱动实现解耦。相比传统按技术或数据库划分的模式，限界上下文能提升团队自治性、部署效率和变更灵活性。代码示例展示了如何通过聚合根和领域事件实现上下文间的协作，体现业务逻辑与架构设计的一致性。
2026-06-01 21:46:49
225
原创 DDD-004：领域、子域与限界上下文
本文摘要： 领域驱动设计（DDD）通过领域、子域和限界上下文划分业务与技术边界。领域是业务问题域，需优先理解；子域分为核心域（高投入）、支撑域（适度投入）和通用域（最小投入）；限界上下文是解决方案的技术边界，实现团队自治。传统开发因忽视领域理解导致业务脱节，而DDD强调业务驱动设计，通过清晰边界降低复杂度。子域与限界上下文可灵活映射（1:1、1:N、N:1），但需避免混淆逻辑边界与微服务等误区。
2026-06-01 21:43:03
454
原创 DDD-003：统一语言（Ubiquitous Language）
文章摘要 统一语言（Ubiquitous Language）是领域驱动设计（DDD）的核心概念，旨在消除业务与开发间的理解偏差。它通过建立共享的业务术语字典，确保需求、代码、测试使用一致的无歧义语言。传统开发中语言混乱导致40%的Bug源于理解偏差，而统一语言能减少75%的理解错误，提升50%的代码审查效率。实施分为三步：创建术语字典（如"下单→placeOrder"）、代码命名统一、持续维护更新。典型案例显示，当业务说"VIP用户"时，代码直接实现isVip()方法，避免level>3与vipStatus
2026-06-01 21:42:25
202
原创 DDD-002：DDD 的战略设计与战术设计
DDD战略设计与战术设计摘要 领域驱动设计(DDD)包含战略设计和战术设计两个层面。战略设计关注宏观系统架构，通过限界上下文划分业务边界，解决传统单体架构中边界模糊、耦合严重等问题。它使用限界上下文、上下文映射和子域划分三大工具，明确系统各部分协作关系和组织分工。战术设计则聚焦微观实现，通过聚合根、实体、值对象等模式构建领域模型。 两者关系上，战略设计为战术设计提供边界约束，而战术设计在战略划分的上下文中实现业务逻辑。DDD适用于业务复杂、团队规模较大的系统，能够显著降低系统复杂度，提高团队协作效率。实际应
2026-06-01 21:41:38
570
原创 DDD-001：DDD 是什么？为什么需要领域驱动设计？
摘要 领域驱动设计（DDD）是一种应对软件复杂性的方法论，通过将业务逻辑封装在领域模型中，解决传统开发模式中业务逻辑分散、代码难以维护的问题。DDD的核心是识别领域概念、建立业务模型，并使用统一语言实现代码与业务的高度一致。 相比传统三层架构，DDD将业务逻辑集中在聚合根内，显著提升代码可读性（方法行数减少79%）、测试覆盖率（提升325%）和开发效率（新功能周期缩短70%）。其长期价值在于保持系统的可维护性，降低认知负荷，使业务知识沉淀在代码中。 DDD特别适合业务复杂度高的系统，但可能不适用于简单CRU
2026-06-01 21:40:58
577
原创 JDK17-21特性Pattern-Matching详解
Java模式匹配(Pattern Matching)是Java 16到21版本逐步引入的重要特性，主要包含instanceof模式匹配和switch模式匹配两种形式。文章详细介绍了模式匹配的演进历程和各版本特性，通过对比传统写法展示了其简化类型检查和数据提取的优势。核心内容包括：instanceof模式匹配的基本用法和流式作用域规则，switch模式匹配的基本语法和守卫条件(when子句)的使用，以及在实际应用中的类型判断和消息处理场景。这些特性显著提升了Java代码的简洁性和安全性，减少了显式类型转换的需
2026-04-27 21:53:31
1327
原创 JDK17-21特性Virtual-Threads详解
Java 21 引入的 Virtual Threads（虚拟线程）是 Project Loom 的核心成果，解决了传统线程的资源消耗大、创建成本高和数量受限等问题。虚拟线程采用 M:N 调度模型，由 JVM 管理而非操作系统，具有轻量级（仅几百字节）、可创建数百万个、高效调度等优势。文章详细介绍了四种创建虚拟线程的方式（Thread.startVirtualThread、Thread.Builder、Executors.newVirtualThreadPerTaskExecutor、ThreadFactor
2026-04-27 21:53:00
526
原创 JDK17-21特性Record类详解
Record类是Java 14引入（Java 16正式版）的新特性，用于创建不可变数据载体类，减少样板代码。Record类是Java数据类的现代解决方案，减少了大量样板代码。
2026-04-27 21:51:54
265
原创 接口默认方法详解
Java 8引入了接口默认方法（Default Methods）和静态方法，允许在接口中提供方法实现，为API演进提供了更好的支持。接口默认方法为Java带来了多继承能力，支持API平滑演进。
2026-04-25 22:24:08
210
原创 Optional类详解
Optional类是Java 8引入的容器类，用于解决空指针异常问题，使代码更加安全和可读。Optional类是解决空指针异常的重要工具，正确使用可以使代码更加安全和可读。
2026-04-25 22:23:32
156
原创 Lambda与Stream详解
Lambda表达式和Stream API是Java 8最重要的新特性，它们为Java带来了函数式编程的能力，使代码更加简洁、易读。│ Lambda表达式语法 ││ ││ 基本语法： ││ (参数列表) -> { 方法体 } ││ ││ 示例： ││ (a, b) -> a + b // 两参数相加 ││ s -> System.out.println(s) // 打印字符串 ││ () -> "Hello" // 无参数返回字符串 ││ (x) -> x * x // 平方 ││ │。
2026-04-25 22:23:00
409
Java技术进阶-从原理到实践.pdf
2026-04-20
C#反编译器（查看dll的软件）
2011-03-20
pb调用dll实例
2013-03-12
MSDN C# 4.0编程指南.rar
2011-04-14
实例md5加密
2013-02-25
c++ dsa数字签名
2013-02-25
日期javascript控件
2011-05-22
css2.0手册chm版
2011-04-14
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人