DDD领域驱动设计
文章平均质量分 66
学些DDD方法论的一些自己学习笔记
Tellme3
任务艰巨在于漫长。
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
22、Event Handler 和event LIstener的区别
本文介绍了事件驱动架构中的关键组件及其在电商订单系统中的应用流程。事件监听器(EventListener)作为被动组件订阅领域事件并触发处理逻辑,事件处理器(EventHandler)则包含具体的业务处理逻辑。通过一个完整的订单处理案例,演示了从用户下单命令(Command)到订单创建事件(DomainEvent),再到事件监听和处理的全过程,包括发送确认邮件和库存扣减等操作。该流程清晰展示了各组件间的协作关系:Command→CommandHandler→DomainEvent→EventListener原创 2025-10-07 01:47:14 · 517 阅读 · 0 评论 -
21、事件(Event) 和 命令(Command) 在 DDD(领域驱动设计) 中的位置
在DDD中,Command和Event具有不同定位:Command属于应用层,表示执行某操作的请求,由CommandHandler触发领域逻辑;而DomainEvent定义在领域层,表示已发生的状态变化,由应用层或基础设施层处理后续流程。简言之,Command是操作的入口,Event是状态的记录。原创 2025-10-07 01:45:39 · 774 阅读 · 0 评论 -
29、六边形架构中的的端口和适配器
本文介绍了六边形架构的核心思想:通过端口(Port)和适配器(Adapter)实现业务逻辑与技术实现的解耦。Domain层定义Port接口(如ProductBOMPort)来声明外部依赖,业务逻辑通过接口访问外部资源而不依赖具体实现。技术实现由基础设施层的Adapter(如ProductBOMRepositoryAdapter)完成,支持多种技术方案。案例展示了工单创建时获取默认BOM的实现过程,体现了Domain只依赖接口、技术变化不影响核心业务的特点。该架构通过依赖反转实现技术解耦,使业务逻辑保持纯粹性原创 2025-09-20 14:29:31 · 699 阅读 · 0 评论 -
28、DDD-六边形架构和四层分层的区分点
四层DDD与六边形架构的核心区别在于关注点不同:四层架构(Controller/Application/Domain/Infrastructure)强调纵向职责分层,明确各层的功能定位,依赖方向自上而下;而六边形架构通过Ports和Adapters实现横向技术解耦,核心思想是让Domain+Application不依赖具体技术实现,支持多方向接入外部系统。两者可叠加使用——四层架构解决"谁做什么"的问题,六边形架构解决"依赖谁/如何接入技术"的问题,共同构建清晰解耦的原创 2025-09-20 14:25:45 · 477 阅读 · 0 评论 -
27、DDD-四层分层说明
DDD四层架构分层清晰,各司其职:1)Controller层处理接口适配;2)应用层协调业务操作;3)领域层专注核心业务逻辑;4)基础设施层实现技术细节。遵循高层依赖低层原则,避免反向依赖。这种分层设计确保了业务与技术解耦,便于系统扩展和维护。原创 2025-09-20 14:23:26 · 731 阅读 · 0 评论 -
架构之冷热数据分离
如何实践区分冷热数据业务代码修改(对代码侵入较高,无法按照时间区分)监听数据库日志(对代码无侵入,但无法按照时间区分)定时任务扫描(可以按照时间区分)热数据:被频繁更新的,还会有所变化的数据,响应时间有要求冷数据: 不允许进行更新的数据(当然具体业务具体分析了),偶尔被查询;响应时间没有要求。原创 2024-05-14 00:42:40 · 1184 阅读 · 0 评论 -
QPS、TPS、RT、并发数
QPS(Queries Per Second):每秒查询数,指的是系统在单位时间内处理的请求数量。QPS通常用于衡量系统的处理能力,特别是在高并发情况下,能够反映系统的性能水平。在网络领域,QPS常用于评估服务器的负载能力,对于网站、API等服务来说,QPS越高,系统的吞吐量就越大,性能就越好。TPS(Transactions Per Second):每秒事务数,指的是系统在单位时间内完成的事务数量。事务可以是数据库的一次读写操作、网络请求的一次处理等。原创 2024-03-24 22:45:57 · 2279 阅读 · 0 评论 -
4、DDD架构建模(实现面向对象模型(停车场案例))
根据我们的需求输入我们面向对象领域模型uml,(是没有发生系统改变,但是我们若是放置到查询模块就把逻辑泄漏出去了,而且此并不是一个复杂查询所以此处放置到命令模块)进场,出场,付费事件可以得出。由进场出场事件可以得出。进场出场失败事件得出。原创 2024-03-10 14:29:22 · 580 阅读 · 0 评论 -
3、DDD与CQRS(命令与查询分开)
CQRS(命令和查询职责分离)职责分离(架构上做分解,也就是一个查询模块,一个命令模块(查询模块依赖命令模块))1、查询模块依赖命令模块我们一般都是稳定的去依赖不稳定的了,查询模块是稳定的,命令模块是不稳定的了2、查询和命令模块,不是简单的读写分离,用来构造一些什么需要读取数据结构的也是属于查询模块的(也就是组装也是在查询模块来做的)3、查询模块和命令模块使用的数据库或者表可以相同也可以不相同,甚至与可以是不同的类型数据库原创 2024-03-09 17:39:11 · 820 阅读 · 0 评论 -
2、DDD六边形架构
代码名称清晰,代码参数清晰我们不能根据参数是如何组装数据的debug才知道这个代码是干什么的,例如代客下单,那么我们需要命名为createOrderForCustomerBySystem(CustomerID),而不能是createOrder(id)这样(RPC调用)就会很不清晰。我们得debug才知道情况原创 2024-03-09 17:38:00 · 447 阅读 · 0 评论 -
1、DDD架构核心方法论
软件设计应该被领域来驱动(也就是领域驱动模型,模型驱动软件设计)领域: 产品需求的问题域模型:是具体写代码设实体类前的挖掘需求和如何设计的考量思考,其中的产出可能就是我们的uml图,或者就在我们脑海中没有具体的uml产出。软件设计: 具体的写实体类了,写对应方法了如何来解释上面的这句话,软件设计就是我们要写的代码,模型就是我们再写代码前的思考架构建立的模型。例如,我们的整体产品是创建一台全知全能的机器人,其中这个机器的一个领域就是说话,那么我们就对说话这个功能进行建模,其中需要机器人id来定位机器人原创 2024-03-09 15:04:24 · 586 阅读 · 0 评论
分享