DDD:策略模式如何结合动态表达式

DDD:策略模式如何结合动态表达式

  企业应用中我们经常会遇到各种业务规则,针对这种规则,我们多数情况会采用策略模式,每种策略对应一个具体类和一个具体的配置界面。但是企业业务的规则经常变化,现有的策略随着时间的推移而不能满足要求,针对这种情况我们可以用动态表达式来解决。

  动态表达式:在静态语言中动态的执行代码,目前可选的技术有:动态编译、Iron、Roslyn、内嵌小语言。

  今天来测试一下内嵌Javascript:

  代码如下:

复制代码
 1 using System;
 2 using System.Collections.Generic;
 3 using System.Linq;
 4 using System.Text;
 5 using System.Threading.Tasks;
 6 
 7 using Noesis.Javascript;
 8 
 9 namespace JavascriptStudy
10 {
11     class Program
12     {
13         static void Main()
14         {
15             var 用户 = new 用户
16             {
17                 年龄 = 20,
18                 工龄 = 5
19             };
20 
21             Console.WriteLine(new 自定义计算公式().计算基本工资(用户));
22         }
23     }
24 
25     internal interface I基本工资计算
26     {
27         Decimal 计算基本工资(用户 用户);
28     }
29 
30     internal class 自定义计算公式 : I基本工资计算
31     {
32         public decimal 计算基本工资(用户 用户)
33         {
34             var context = new JavascriptContext();
35 
36             context.SetParameter("用户", 用户);
37 
38             const string expression = @"用户.工龄 * 200."; //真实项目从数据库获取
39 
40             var result = context.Run(expression);
41 
42             if (result is int)
43             {
44                 return (int)result;
45             }
46 
47             return (decimal)(float)result;
48         }
49     }
50 
51     internal class 用户
52     {
53         public int 年龄 { get; set; }
54 
55         public int 工龄 { get; set; }
56     }
57 }
复制代码
 
摘要: 企业应用中我们经常会遇到各种业务规则,针对这种规则,我们多数情况会采用策略模式,每种策略对应一个具体类和一个具体的配置界面。但是企业业务的规则经常变化,现有的策略随着时间的推移而不能满足要求,针对这种情况我们可以用动态表达式来解决。 动态表达式:在静态语言中动态的执行代码,目前可选的技术有:动态编译、Iron、Roslyn、内嵌小语言。 今天来测试一下内嵌Javascript: 代码如下: 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 us... 阅读全文
posted @  2013-04-01 17:49 幸福框架 阅读(52) |  评论 (0)  编辑
 
摘要: 重构与模式(修订版)当当网¥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 幸福框架 阅读(254) |  评论 (7)  编辑
 
摘要: 第一种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 幸福框架 阅读(19) |  评论 (0)  编辑
 
摘要: 场景 修改用户名时,要验证用户名的唯一性。实现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.... 阅读全文
posted @  2013-03-26 09:28 幸福框架 阅读(25) |  评论 (0)  编辑
 
摘要: PPT对应某个聚合。Des对应某个聚合或其它聚合内的实体或值对象。MI对应某个聚合。Role对应PPT(Data)在某个上下文(Context)执行某些交互(Interactive)的代理或装饰器。四色原型中的一些静态方法需要移动到仓储或服务中。 阅读全文
posted @  2013-03-24 13:54 幸福框架 阅读(12) |  评论 (0)  编辑
 
摘要: CQRS架构的选择?系统的分层策略?应用层的组织风格?是否采用EventDriven?这些统统和咱们讨论的话题没关系,换句话说:“无论您采用贫血模型或领域模型,您都可以选择之上的技术”。 贫血模型和领域模型从OO的角度考虑,前者缺少“封装”,换句话说:“无论您采用贫血模型或领域模型,您都可以用好继承和多态”。 封装带来的最大好处就是依赖性的降低和可维护性的提高。 阅读全文
posted @  2013-03-23 16:07 幸福框架 阅读(19) |  评论 (0)  编辑
 
摘要: 《精通.NET企业项目开发:最新的模式、工具与方法》《.NET应用架构设计:原则、模式与实践》《ASP.NET设计模式》《Microsoft .NET企业级应用架构设计》《领域驱动设计C#2008实现》《领域驱动设计与模式实战》《领域驱动设计》 阅读全文
posted @  2013-03-22 13:27 幸福框架 阅读(49) |  评论 (1)  编辑
 
摘要: 仓储接口在领域层。仓储实现在基础设层。仓储的主要职责是处理聚合的和持久化相关的任务(ADD、UPDATE、DELETE、GET)。仓储不应当实现业务逻辑,如:ADD操作的前置条件(用户名必须唯一)。 结论:如果是这样,应用层是不是最好不要直接用仓储,因为仓储没有封装业务逻辑,直接用可能会绕过业务逻辑。 阅读全文
posted @  2013-03-20 14:13 幸福框架 阅读(14) |  评论 (0)  编辑
 
摘要: MI和MIDetail属于同一个聚合。MI和MIdetail不能持有对PPT的引用,只能存储其快照。PPT多数情况是一个聚合就一个聚合根;Description对PPT的描述,可以表示为一个标识引用或将Description做为值对象。Description多数情况是一个聚合就一个聚合根。Role多数情况可以视作一个领域服务。四色原型间的关系通过仓储进行导航。 阅读全文
posted @  2013-03-16 08:56 幸福框架 阅读(19) |  评论 (0)  编辑
 
摘要: 了解同一个边界中的真正的不变量 聚合的划分是需要细心设计的,聚合划分时除了根据聚合本身的定义外还应该能保证聚合内部元素的一致性,当外界通过聚合根对聚合内的元素进行修改时能使改变的元素与其他元素之间保持设定的一致性,确保概念上的不变。 尽量设计小的聚合 聚合设计大多数时候都会受到主观因素的影响,有的人喜欢设计大聚合(聚合包含的实体和值对象数量太多),因为觉得大聚合容易获得聚合内的其他元素,这样做虽然表面上看起来很方便,但是存在很大的弊端,大聚合在进行数据操作时不容易控制,容易造成事务失败,因此应该尽量设计小的聚合。 不同聚合之间通过唯一标识来关联 聚合A和聚合B之间存在关联,并且在... 阅读全文
posted @  2013-03-14 11:21 幸福框架 阅读(20) |  评论 (1)  编辑
 
摘要: 聚合 = 聚合根 + 实体 + 值对象 + 导航约束: 只有“聚合根”可以被其它对象“导航”到,“内部实体”只能被临时使用。 ”内部实体“和”值对象“在概念上只被所在的聚合根使用(本地标识)。 ”内部实体“和”值对象“可以导航到其它”聚合根“。设计原则 同时生存同时消亡(充分条件)。 存在不变量(充分条件)。 容易管理并发(充分条件)。 不可缺少的一部分(充分条件)。 同时加载同时保存(充分必要条件)。 阅读全文
posted @  2013-03-12 18:26 幸福框架 阅读(35) |  评论 (1)  编辑
 
摘要: 业务事务面向用例,一般一个请求对应一个业务事务,一个业务事务对应多个数据库事务,一个业务事务运行在一个分布式事务中,一个数据库事务最好只操作一个聚合。 如何编排一个业务事务的多个数据事务呢?一、DomainService(推荐);二、DomainEvent(推荐);三、ApplicationService(不推荐)。 如何管理分布式事务呢?一、AOP;二、AOP、三、AOP。 阅读全文
posted @  2013-03-11 19:21 幸福框架 阅读(50) |  评论 (0)  编辑
 
摘要: Command:纵向传递,跨分层,在控制器层和应用层之间传递。DomainEvent:横向传递,跨聚合,在一个DLL中。ApplicationEvent:横向传递,跨模块,在不同的DLL中。 阅读全文
posted @  2013-03-09 13:48 幸福框架 阅读(33) |  评论 (1)  编辑
 
摘要: 1、识别模型(内部视图):实体、值对象、聚合、服务、工厂、仓储、领域事件。2、识别命令(外部视图):命令、处理器、应用事件。 阅读全文
posted @  2013-03-08 11:30 幸福框架 阅读(22) |  评论 (0)  编辑
 
摘要: 用来组织业务逻辑面向业务逻辑。细粒度。内部视图看系统。一个请求对应多个服务的多个方法。服务之间会存在依赖。职责一般包括:夸聚合协调、没办法合理放到实体中的其它领域逻辑。 阅读全文
posted @  2013-03-05 11:11 幸福框架 阅读(32) |  评论 (0)  编辑
 
摘要: 用来封装业务逻辑面向用例。粗粒度。外部视图看系统。一个请求对应一个方法。服务之间不相互调用。职责一般包括:跨模块协调、DTO转换、事务AOP、权限AOP、日志AOP、异常AOP、邮件、消息队列。 阅读全文
posted @  2013-03-02 11:39 幸福框架 阅读(28) |  评论 (0)  编辑
 
摘要: 思路实体见引入合理的关联。根据需要引入聚合。将DAL命名的类换成Repository命名。将BAL命名的类换成Service。将BAL中的一些职责重构到Domain中。引入Applicaiton层。根据需要引入ViewModel和Mapper。根据需要引入工作单元。小心ORM工具提供的主键映射功能。推荐引入IoC容器。推荐引入AOP。 阅读全文
posted @  2013-02-28 11:34 幸福框架 阅读(49) |  评论 (2)  编辑
 
摘要: 刚开始的代码 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 幸福框架 阅读(34) |  评论 (0)  编辑
 
摘要: http://www.cnblogs.com/daxnet/archive/2011/12/24/2300169.htmlhttp://www.cnblogs.com/netfocus/archive/2011/01/17/1937779.htmlhttp://dddcommunity.org/library/vernon_2011/ 阅读全文
posted @  2013-02-07 21:00 幸福框架 阅读(17) |  评论 (0)  编辑
 
摘要: 三者的技术实现模式一样,都是基于消息、总线和处理器这种风格,可以共享基类。DomainEvent关注领域层事件,处理跨聚合协调。ApplicaitonEvent关注应用层事件,处理跨模块调用。Command关注用例事件,处理跨层协调。 阅读全文
posted @  2013-02-06 22:38 幸福框架 阅读(14) |  评论 (0)  编辑
 
分类:  DDDDesign Pattern

你可能感兴趣的:(策略模式)