DDD的思考

关于DDD的思考
1、聚合根尽量要小,封装了聚合根内部的所有操作;外部必须通过聚合根才能访问聚会里面的内容;
2、多个聚合根一起工作,需要通过领域服务或者事件来完成协调工作;
3、Repository是聚合根的仓储,用于储存聚合根的数据;IRepository的定义放在领域Domain,Repository的实现放在基础设施层,这样就可以做到领域不依赖基础设施层,而仅仅依赖接口;
4、一个聚合的新增:

1>、引用层通过领域仓储获取领域聚合根Gid,通过聚合根内部方法,完成内部操作,返回聚合根数据,应用层通过基础设施层,更新数据到DB;

5、一个聚合根的修改:

1>、应用层通过仓储获取领域层中的聚合根;
2>、通过领域层的聚合根完成相应的数据操作,更新仓储数据,返回最新聚合根数据;
3>、应用层通过基础设施层更新数据到DB;

时间: 2025-01-31 07:36:18

DDD的思考的相关文章

(DDD)仓储的思考

(DDD)仓储的思考 为什么需要仓储呢?领域对象(一般是聚合根)的被创建出来后的到最后持久化到数据库都需要跟数据库打交道,这样我们就需要一个类似数据库访问层的东西来管理领域对象.那是不是我们就可以设计一个类似DAL层的东东来管理对象呢?是的,但是呢设计上有点区别,就是我们不希望上层如应用层直接访问数据,我们所有的操作应该是围绕着领域对象来的,所以我们还设计了仓储接口在领域层,然后把仓储的实现放在基础设施层.这样的设计模式很常见,一般用来解耦的.但是仓储不处理事务,事务处理我们一般交给UnitOf

关于DDD中Domain的思考

本文既不推销UML,也不推广DDD,更不涉及各种论战.-- 作者 某天又一次打开关于DDD(领域驱动设计)的PDF文档时,自己有了个疑问:什么是领域(Domain)?译文中是这样描述领域:银行业务被银行的内部人员和专家所熟知.他们知道所有的细节.所有的困难.所有可能 出现的问题.所有的业务规则.这些就是我们永远的起始点:领域.如果这就是领域,它似乎不是"起始点",而是"全部"--全部的业务规则.全部的细节.全部可能出现的问题.我的疑问正是始于此:Domain映射到软

关于领域驱动设计(DDD)仓储的思考

为什么需要仓储呢?领域对象(一般是聚合根)的被创建出来后的到最后持久化到数据库都需要跟数据库打交道,这样我们就需要一个类似数据库访问层的东西来管理领域对象.那是不是我们就可以设计一个类似DAL层的东东来管理对象呢?是的,但是呢设计上有点区别,就是我们不希望上层如应用层直接访问数据,我们所有的操作应该是围绕着领域对象来的,所以我们还设计了仓储接口在领域层,然后把仓储的实现放在基础设施层.这样的设计模式很常见,一般用来解耦的.但是仓储不处理事务,事务处理我们一般交给UnitOfWork,有关于Uni

DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考

之前,在用ENode开发forum案例时,遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题.后来找到了自己认为比较合理的解决方案,分享给大家.也希望能和大家交流,擦出更多的火花. 论坛核心领域问题分析 论坛领域的核心概念是:帖子.回复.大家都知道,一个帖子可以有零个或多个回复.对同一个帖子,不同的人可以并行发表回复.回复发表后,查看帖子详情时,可以根据回复的发表时间排序显示:此外,我们还关心某个帖子的最新发表的回复.最新回复的作者.最新回复时间,以及总回复数. 我们设计的系统,应该在实现

关于领域驱动架构DDD思考

一个高大上的概念领域驱动架构就这样展开. 开发了多年的软件,一直以来的习惯是拿到产品的需求 对照UI的图纸然后就干干干 碰到问题大不了找人沟通再次定义问题,最后交付.其实最后也能把一件事情完成 但如果碰到很大型的项目,面对里面的各个模块 你会感觉无从下手,甚至都无法创造,理不清种种,有冲动想画画在纸上 又无从下手. 如果一开始能从更高层面的角度去设计系统 一步一步 那之后的事情 其实只是填充代码了,其实这种能力往往比编码更重要. 涉及到几个概念:心智建模 数据建模 心智建模一般还停留在会议层次上

DDD CQRS架构和传统架构的优缺点比较

明天就是大年三十了,今天在家有空,想集中整理一下CQRS架构的特点以及相比传统架构的优缺点分析.先提前祝大家猴年新春快乐.万事如意.身体健康! 最近几年,在DDD的领域,我们经常会看到CQRS架构的概念.我个人也写了一个ENode框架,专门用来实现这个架构.CQRS架构本身的思想其实非常简单,就是读写分离.是一个很好理解的思想.就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.关于CQRS架构的介绍其实已经非常

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型:

(转载)浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故

DDD & 重构—— 写在前面

最近新接了一个业务系统——社区服务系统,为了快速熟悉和梳理老系统的业务逻辑和代码,同时对老系统代码做一些优化,于是打算花上一个月时间不间断地对老系统服务进行重构.同时,考虑到社区业务的复杂性,想起了之前做用户系统时尝试过的领域驱动建模(简称DDD,英文全称为:Domain Driven Design),思量之下,觉得DDD非常时候这种复杂业务逻辑的系统.毫不迟疑,开搞! 之前在做用户系统时,也尝试使用DDD进行业务建模,但迫于项目工期压力,没有进行深入的学习和建模,最后效果不是很理想,为了避免重