随笔分类 -  DDD

领域驱动设计(Domain Driven Design)。
DDD:整理了一些关于验证方面的文章
摘要:http://msdn.microsoft.com/en-us/library/ff664356(v=pandp.50).aspxhttp://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/http://lostechies.com/jimmybogard/2009/02/15/validation-in-a-ddd-world/http://abdullin.com/journal/2009/1/29/ddd-and-rule-driven-ui-validation-in-net.htmlhttp 阅读全文

posted @ 2013-06-19 17:01 幸福框架 阅读(647) 评论(0) 推荐(0) 编辑

DDD:如何处理“唯一性”业务逻辑
摘要:背景唯一性约束是一个经常出现的业务逻辑,刚开始我觉得非常简单,不过深入考虑后,发现实现起来还不是那么简单,下面就让我们分析一下。两种场景下的唯一性约束第一种场景:聚合根的某个属性的唯一性约束示例:用户的用户名必须唯一。第一种实现思路:后验证+不用数据库索引,在插入用户名和修改用户名之后执行一次验证,这个验证逻辑执行的事务隔离级别必须处于“读未提交”级别。 1 public volid Insert(User user) 2 { 3 using(var ts1 = new TransactionScope("读已提交")) 4 { 5 DoInsert(user)... 阅读全文

posted @ 2013-06-15 21:14 幸福框架 阅读(2094) 评论(0) 推荐(1) 编辑

DDD:聚合(根)、实体、值对象精炼思考总结(转载)
摘要:原文链接:http://www.cnblogs.com/netfocus/archive/2012/02/12/2347938.html。1. 聚合根、实体、值对象的区别?从标识的角度:聚合根具有全局的唯一标识,而实体只有在聚合内部有唯一的本地标识,值对象没有唯一标识,不存在这个值对象或那个值对象的说法;从是否只读的角度:聚合根除了唯一标识外,其他所有状态信息都理论上可变;实体是可变的;值对象是只读的;从生命周期的角度:聚合根有独立的生命周期,实体的生命周期从属于其所属的聚合,实体完全由其所属的聚合根负责管理维护;值对象无生命周期可言,因为只是一个值;2. 聚合根、实体、值对象对象之间如何建立 阅读全文

posted @ 2013-06-14 22:43 幸福框架 阅读(2404) 评论(0) 推荐(1) 编辑

DDD:在基于关系数据库的领域,聚合的边界等于并发管理的边界。
摘要:背景领域驱动中关于聚合设计的原则一直存在一个模糊的定义,比如:不变量、一致性和一个边界。根据这些规则很难清晰的划分聚合,不排除聚合的设计有一定的艺术性,但是在限定的领域内或许有某种可以明确遵循的规则,前几天我好像思考到了这样一个规则,这里分享给大家,跪求批评。规则(在基于关系数据库的领域,聚合的边界等于并发管理的边界。)为了满足不变量和一致性,毫无疑问我们要采用并发管理。正确的聚合设计下图中只有一个聚合实例,在聚合根中应用乐观锁保证聚合的一致性,一个聚合必须做为一个整体进行操作,如:客户端修改“明细”时,其加载和保存的JSON数据必须包含“聚合根”。错误的聚合设计下图中只有三个聚合实例,在聚合 阅读全文

posted @ 2013-06-08 08:59 幸福框架 阅读(1663) 评论(5) 推荐(2) 编辑

DDD:聚合根的批量删除是不是可以批量发送请求
摘要:背景搞了近五年的系统开发,总是抱着一种思维模式,用户的一个操作对应一个请求和一个事务,比如:用户选择了N条记录,我就会向服务器发生一个请求,服务器在一个事务中进行处理。前几天在群里一个前辈反问:批量操作难道真的要在一个事务中?这个问题让陷入了反思,谢谢前辈们(魏琼东)。DDD中有聚合的概念,一个聚合有且只有一个聚合根和一些其他实体,如:订单聚合中,订单是聚合根,订单明细是聚合内的实体。因为DDD中只能操作聚合根,这篇文章就介绍聚合根的批量删除问题。有人问聚合内的实体的删除咋弄?聚合内实体的删除必须伴随着聚合根的修改(这里不做详细介绍)。另外一点是需要注意的是,引入工作单元之后,批量操作和单个操 阅读全文

posted @ 2013-06-01 09:07 幸福框架 阅读(2285) 评论(3) 推荐(0) 编辑

DDD:Evans 开始关注NOSQL + 用户体验(转载)
摘要:原文链接:http://dddcommunity.org/events/ddd-summit-2012/。Left to right: Rinat Abdullin, Jimmy Nilsson, Vaughn Vernon, Cameron Purdy, Dan Berg Johnsson, Randy Stafford, Daniel Gackle, Patrik Fredriksson, Eric Evans, Paul Rayner, Alberto Brandolini, Rebecca Wirfs-Brock, Andreas Brink, and our photographer 阅读全文

posted @ 2013-05-26 23:55 幸福框架 阅读(738) 评论(0) 推荐(0) 编辑

DDD:如何保证聚合的一致性
摘要:聚合一致性从时间维度考虑,一致性分为“实时一致性”和“最终一致性”。在企业应用中,多数情况都是使用实时一致性。在WEB应用中,为了最大限度的提高系统的吞吐量,经常使用最终一致性,如:博客园的积分和排名计算。从聚合的维度考虑,一致性分为“内部一致性”和“外部一致性”。内部一致性是指一个聚合实例本身状态的一致性。外部一致性是指多个聚合实例之间状态的一致性。代码示例需求订单要记录订单原始总额。(内部一致性)订单有两种状态,未提交和提交,不能修改已提交的订单。(内部一致性)订单要记录订单的总额,总额 = 原始总额 * 折扣,如果客户是VIP就打8折。(外部一致性)客户信用评级。(最终一致性)类图核心代 阅读全文

posted @ 2013-05-06 00:06 幸福框架 阅读(2606) 评论(3) 推荐(1) 编辑

DDD:用 “四色原型” 进行 “职责分配”
摘要:这篇博客是DDD:用 “四色原型” 进行 “聚合设计”的延伸版。职责分配聚合维护内部状态的一致性。换句话说,聚合的职责只限于维护期自身的状态。可以将聚合的职责分为两类:修改职责:只能修改聚合本身的状态,关联的其它聚合信息不能修改。读取职责:可以读取聚合本身的状态,关联的其它聚合信息也能读取。角色维护一个聚合实例业务逻辑的一致性。因为有些聚合实例的业务逻辑会依赖很多外部服务:如仓储、领域服务等。常见的场景如下:前置条件:修改内部状态时,必须满足的条件。唯一性验证:某些状态必须唯一。计算逻辑:此处多数采用状态模式或策略模式。领域服务维护多个聚合实例(跨聚合)业务逻辑的一致性。工厂维护聚合的创建逻辑 阅读全文

posted @ 2013-04-26 13:30 幸福框架 阅读(2935) 评论(4) 推荐(0) 编辑

DDD:用 “四色原型” 进行 “聚合设计”
摘要:四色原型在企业应用的上下文中,四色原型是领域模型的一种原型,原型的意思是指领域中的任何模型及其关系都可以抽象为“四色原型”。四色原型可以用这句话进行描述:某个人(Party)的角色(PartyRole)在某个地点(Place)的角色(PlaceRole)用某个东西(Thing)的角色(ThingRole)做了某件事情(MomentInterval)。图片示意名词解释PartPlaceThing:简称PPT,用淡绿色表示,常见的PPT有:部门、岗位、人员、地点、物品等。Description:简称Des,用淡蓝色表示,主要用来对PPT进行描述,常见的Des有:部门类型、岗位层级、人员类型、地点区 阅读全文

posted @ 2013-04-26 07:02 幸福框架 阅读(13371) 评论(11) 推荐(9) 编辑

DDD:主键映射,你一直在使用的企业应用模式
摘要:名称解释主键映射是为了保证一个业务事务(请求)内只访问或修改一份领域模型。基本的思路是在内存中维护一个映射表,映射表的键为领域模型的主键,值为加载的领域模型。工作原理如下:根据主键加载:先判断映射中有没有,有就直接从映射中返回,没有就从数据库加载,然后添加进映射再返回。根据查询加载:先从数据库加载所有满足条件的领域模型集合,然后遍历这个集合,用1的算法处理每个加载的领域模型,返回新的集合(集合.Map算法)。总之,主键映射会保证整个业务事务发生的过程你只会引用到一个内存引用,你自己实现主键映射也要保证这个语义。图片示意不用主键映射会出现什么问题?using System;using Micro 阅读全文

posted @ 2013-04-25 13:17 幸福框架 阅读(1841) 评论(2) 推荐(0) 编辑

DDD:DDD+CQRS+高伸缩性的分布式架构
摘要:物理架构物理架构优势WEB服务器可以单独做负载平衡(独立伸缩)。应用服务可以单击做负载平衡(独立伸缩)。容易引入“后台任务服务器”(正在做这方面的支持)。支持混合部署(一部分业务逻辑运行在WEB服务器,一部分业务逻辑运行在应用服务器),部署方式对开发人员几乎透明。如何选择部署模型当用户数少(自己测试)的时候可以不用应用服务器,只做WEB负责平衡。当用户数多(自己测试)的时候,将频繁执行的业务逻辑分离部署到应用服务器上。对于那些长时间(自己测试)执行的任务,将它们部署到后台任务服务器上。示例代码项目结构WEB服务器代码 1 using System; 2 using System.Collect 阅读全文

posted @ 2013-04-19 14:26 幸福框架 阅读(6136) 评论(14) 推荐(3) 编辑

DDD:管理“工作单元实例”的两种模式
摘要:概念介绍类图如下:在常见的用例场景下,类图的对象图如下:问题在一个用例执行过程中,如何保证同一个界限上下文内的所有仓储实例可以共享同一个工作单元实例?解决方案1仓储采用依赖注入模式 + 使用IOC管理工作单元的生命周期(PerRequest或其它)。代码示例 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 7 using Autofac; 8 9 namespace AutoFacSt.. 阅读全文

posted @ 2013-04-18 07:41 幸福框架 阅读(4375) 评论(11) 推荐(3) 编辑

DDD:拥抱幸福之道(DDD&CQRS)
摘要:感谢软件架构群(109404699)今天有机会参加这个群的一个线下的交流活动,本着“积极分享"和"不怕被批”的原则,我主动要求分享一下我对DDD和CQRS的一点认识。准备这次主题演讲的过程让我对DDD和CQRS有了更深刻的认识,这个过程迫使我主动的思考了很多内容。我在此想呼吁的是:技术人员要试着走出去,多积极的参与线上交流和线下交流。关于这次交流的收获,下周一我会好好总结一下。推荐的两个领域驱动群(32066589、14138539)我演讲的PPT(下载地址) 阅读全文

posted @ 2013-04-13 23:34 幸福框架 阅读(2019) 评论(1) 推荐(1) 编辑

DDD:DDD+CQRS架构中的数据库访问技术
摘要:从数据采集和使用的角度可以将系统分为OLTP和OLAP两类,这样的划分正好对应了CQRS架构下的Command(OLTP)部分和Query(OLAP)部分。 Query的组织方式多采用ViewModel+RawSql。 Command的组织方式多采用DDD+ORM,其中Command执行的操作可以细分为单个操作和批量操作,单个操作使用ORM肯定不成问题,批量操作可以采用RawSql或后台任务的形式。判定树OLAP(Query)RawSqlOLTP(Command)Single OperationORMBatch OperationRawSqlORM in Background备注即使是... 阅读全文

posted @ 2013-04-07 14:29 幸福框架 阅读(1784) 评论(1) 推荐(1) 编辑

DDD:策略模式如何结合动态表达式
摘要:企业应用中我们经常会遇到各种业务规则,针对这种规则,我们多数情况会采用策略模式,每种策略对应一个具体类和一个具体的配置界面。但是企业业务的规则经常变化,现有的策略随着时间的推移而不能满足要求,针对这种情况我们可以用动态表达式来解决。动态表达式:在静态语言中动态的执行代码,目前可选的技术有:动态编译、Iron、Roslyn、内嵌小语言。今天来测试一下内嵌Javascript:代码如下: 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using Syst 阅读全文

posted @ 2013-04-01 17:49 幸福框架 阅读(1025) 评论(0) 推荐(0) 编辑

DDD:我的购书清单(欢迎借读,邮费自理)
摘要:重构与模式(修订版)当当网¥42.50(77折)2013-01-30 00:09:155615274300发表评价代码阅读(权威精选植根于开发实践的最佳读...当当网¥61.10(77折)2012-12-30 10:59:105465865000发表评价代码质量(权威精选植根于开发实践的最佳读...当当网¥71.20(80折)2012-12-30 10:59:105465865000发表评价面向对象分析与设计(第3版)(权威精选植...当当网¥78.10(79折)2012-12-30 10:59:105465865000发表评价敏捷技能修炼:敏捷软件开发与设计的最佳实...当当网¥44.40( 阅读全文

posted @ 2013-03-29 17:17 幸福框架 阅读(969) 评论(9) 推荐(1) 编辑

DDD:应用层的三种组织风格
摘要:第一种1 public class ApplicationService2 {3 public void Create(string username, string password);4 5 //xxx其它方法 6 }第二种1 public class ApplicationService2 {3 public CreateUserResponse Create(CreateUserRequest request);4 5 //xxx其它方法 6 }第三种1 public class CreateUserCommand {}2... 阅读全文

posted @ 2013-03-27 09:24 幸福框架 阅读(2151) 评论(1) 推荐(0) 编辑

DDD:实体如何处理外部依赖
摘要:场景修改用户名时,要验证用户名的唯一性。实现11 public class User2 {3 public void ChangeUsername(string newUsername)4 { 5 //使用服务定位器获取IUsernameUniqueService ,执行验证。6 }7 }实现2 1 public class User 2 { 3 public void ChangeUsername(string newUsername) 4 { 5 EventBus.Se... 阅读全文

posted @ 2013-03-26 09:28 幸福框架 阅读(1104) 评论(0) 推荐(0) 编辑

DDD:四色原型、DDD、DCI之间的关系
摘要:PPT对应某个聚合。Des对应某个聚合或其它聚合内的实体或值对象。MI对应某个聚合。Role对应PPT(Data)在某个上下文(Context)执行某些交互(Interactive)的代理或装饰器。四色原型中的一些静态方法需要移动到仓储或服务中。 阅读全文

posted @ 2013-03-24 13:54 幸福框架 阅读(2407) 评论(0) 推荐(0) 编辑

DDD:贫血模型和领域模型的一些思考
摘要:CQRS架构的选择?系统的分层策略?应用层的组织风格?是否采用EventDriven?这些统统和咱们讨论的话题没关系,换句话说:“无论您采用贫血模型或领域模型,您都可以选择之上的技术”。贫血模型和领域模型从OO的角度考虑,前者缺少“封装”,换句话说:“无论您采用贫血模型或领域模型,您都可以用好继承和多态”。封装带来的最大好处就是依赖性的降低和可维护性的提高。 阅读全文

posted @ 2013-03-23 16:07 幸福框架 阅读(1353) 评论(0) 推荐(0) 编辑

导航

我要啦免费统计