随笔分类 -  DDD

领域驱动设计(Domain Driven Design)。
DDD:介绍领域驱动的图书
摘要:《精通.NET企业项目开发:最新的模式、工具与方法》《.NET应用架构设计:原则、模式与实践》《ASP.NET设计模式》《Microsoft .NET企业级应用架构设计》《领域驱动设计C#2008实现》《领域驱动设计与模式实战》《领域驱动设计》 阅读全文

posted @ 2013-03-22 13:27 幸福框架 阅读(1126) 评论(1) 推荐(2) 编辑

DDD:仓储的职责
摘要:仓储的职责仓储接口在领域层。仓储实现在基础设层。仓储的主要职责是处理聚合的和持久化相关的任务(ADD、UPDATE、DELETE、GET)。仓储不应当实现业务逻辑,如:ADD操作的前置条件(用户名必须唯一)。结论:如果是这样,应用层是不是最好不要直接用仓储,因为仓储没有封装业务逻辑,直接用可能会绕过业务逻辑。 阅读全文

posted @ 2013-03-20 14:13 幸福框架 阅读(1188) 评论(0) 推荐(0) 编辑

DDD:通过四色原型来理解聚合
摘要:MI和MIDetail属于同一个聚合。MI和MIdetail不能持有对PPT的引用,只能存储其快照。PPT多数情况是一个聚合就一个聚合根;Description对PPT的描述,可以表示为一个标识引用或将Description做为值对象。Description多数情况是一个聚合就一个聚合根。Role多数情况可以视作一个领域服务。四色原型间的关系通过仓储进行导航。 阅读全文

posted @ 2013-03-16 08:56 幸福框架 阅读(1553) 评论(0) 推荐(0) 编辑

DDD:子龙关于聚合的总结
摘要:了解同一个边界中的真正的不变量聚合的划分是需要细心设计的,聚合划分时除了根据聚合本身的定义外还应该能保证聚合内部元素的一致性,当外界通过聚合根对聚合内的元素进行修改时能使改变的元素与其他元素之间保持设定的一致性,确保概念上的不变。尽量设计小的聚合聚合设计大多数时候都会受到主观因素的影响,有的人喜欢设计大聚合(聚合包含的实体和值对象数量太多),因为觉得大聚合容易获得聚合内的其他元素,这样做虽然表面上看起来很方便,但是存在很大的弊端,大聚合在进行数据操作时不容易控制,容易造成事务失败,因此应该尽量设计小的聚合。不同聚合之间通过唯一标识来关联聚合A和聚合B之间存在关联,并且在使用聚合A时,经常需要用 阅读全文

posted @ 2013-03-14 11:21 幸福框架 阅读(558) 评论(1) 推荐(0) 编辑

DDD:关于聚合的思考
摘要:聚合 = 聚合根 + 实体 + 值对象 + 导航约束只有“聚合根”可以被其它对象“导航”到,“内部实体”只能被临时使用。”内部实体“和”值对象“在概念上只被所在的聚合根使用(本地标识)。”内部实体“和”值对象“可以导航到其它”聚合根“。设计原则 同时生存同时消亡(充分条件)。 存在不变量(充分条件)。 容易管理并发(充分条件)。 不可缺少的一部分(充分条件)。 同时加载同时保存(充分必要条件)。 阅读全文

posted @ 2013-03-12 18:26 幸福框架 阅读(663) 评论(1) 推荐(1) 编辑

DDD:业务事务、数据库事务、分布式事务
摘要:业务事务面向用例,一般一个请求对应一个业务事务,一个业务事务对应多个数据库事务,一个业务事务运行在一个分布式事务中,一个数据库事务最好只操作一个聚合。如何编排一个业务事务的多个数据事务呢?一、DomainService(推荐);二、DomainEvent(推荐);三、ApplicationService(不推荐)。如何管理分布式事务呢?一、AOP;二、AOP、三、AOP。 阅读全文

posted @ 2013-03-11 19:21 幸福框架 阅读(2185) 评论(0) 推荐(0) 编辑

DDD:DomainEvent、ApplicationEvent、Command
摘要:Command:纵向传递,跨分层,在控制器层和应用层之间传递。DomainEvent:横向传递,跨聚合,在一个DLL中。ApplicationEvent:横向传递,跨模块,在不同的DLL中。 阅读全文

posted @ 2013-03-09 13:48 幸福框架 阅读(1789) 评论(1) 推荐(1) 编辑

DDD:开发思路
摘要:1、识别模型(内部视图):实体、值对象、聚合、服务、工厂、仓储、领域事件。2、识别命令(外部视图):命令、处理器、应用事件。 阅读全文

posted @ 2013-03-08 11:30 幸福框架 阅读(859) 评论(0) 推荐(0) 编辑

DDD:领域层服务的设计原则
摘要:用来组织业务逻辑面向业务逻辑。细粒度。内部视图看系统。一个请求对应多个服务的多个方法。服务之间会存在依赖。职责一般包括:夸聚合协调、没办法合理放到实体中的其它领域逻辑。 阅读全文

posted @ 2013-03-05 11:11 幸福框架 阅读(1717) 评论(0) 推荐(0) 编辑

DDD:应用层服务的设计原则
摘要:用来封装业务逻辑面向用例。粗粒度。外部视图看系统。一个请求对应一个方法。服务之间不相互调用。职责一般包括:跨模块协调、DTO转换、事务AOP、权限AOP、日志AOP、异常AOP、邮件、消息队列。 阅读全文

posted @ 2013-03-02 11:39 幸福框架 阅读(2770) 评论(0) 推荐(1) 编辑

DDD:传统三层架构向DDD的转换
摘要:思路实体见引入合理的关联。根据需要引入聚合。将DAL命名的类换成Repository命名。将BAL命名的类换成Service。将BAL中的一些职责重构到Domain中。引入Applicaiton层。根据需要引入ViewModel和Mapper。根据需要引入工作单元。小心ORM工具提供的主键映射功能。推荐引入IoC容器。推荐引入AOP。 阅读全文

posted @ 2013-02-28 11:34 幸福框架 阅读(2653) 评论(2) 推荐(4) 编辑

DDD:将概念显式化 之 验证规约
摘要:刚开始的代码 1 class 将概念显式化1 2 { 3 public void 请假(Guid employeeId, DateTime startDate, DateTime endDate) 4 { 5 var 剩余天数 = 获取员工可以请假的剩余天数(employeeId); 6 var 请假天数 = (endDate - startDate).Days; 7 8 if (请假天数 > 剩余天数) 9 {10 ... 阅读全文

posted @ 2013-02-27 09:45 幸福框架 阅读(823) 评论(1) 推荐(0) 编辑

DDD:大牛们关于聚合的理解
摘要:http://www.cnblogs.com/netfocus/archive/2011/01/17/1937779.html(汤雪华大哥)http://www.cnblogs.com/daxnet/archive/2011/12/24/2300169.htmlhttp://dddcommunity.org/library/vernon_2011/ 阅读全文

posted @ 2013-02-07 21:00 幸福框架 阅读(1275) 评论(1) 推荐(0) 编辑

DDD:DomainEvent、ApplicationEvent、Command
摘要:三者的技术实现模式一样,都是基于消息、总线和处理器这种风格,可以共享基类。DomainEvent关注领域层事件,处理跨聚合协调。ApplicaitonEvent关注应用层事件,处理跨模块调用。Command关注用例事件,处理跨层协调。 阅读全文

posted @ 2013-02-06 22:38 幸福框架 阅读(961) 评论(0) 推荐(0) 编辑

导航

我要啦免费统计