文档库 最新最全的文档下载
当前位置:文档库 › 基于“事件”驱动的领域驱动设计(DDD)框架分析及Demo演示

基于“事件”驱动的领域驱动设计(DDD)框架分析及Demo演示

基于“事件”驱动的领域驱动设计(DDD)框架分析及Demo演示
基于“事件”驱动的领域驱动设计(DDD)框架分析及Demo演示

从去年10月份开始,学了几个月的领域驱动设计(Domain Driven Design,简称DDD)。主要是学习领域驱动设计之父Eric Evans的名著:《Domain-driven design:领域驱动设计:软件核心复杂性应对之道》,以及另外一本Martin Flower的《企业应用架构模式》,学习到了不少关于如何组织业务逻辑方面的知识。另外,在这个过程中也接触到了一些开源的架构和一些很好的思想。如:命令查询职责分离(Command Query Responsibility Segregation,简称CQRS),事件驱动架构(Event Driven Architecture,简称EDA),以及四色原型和DCI架构,等等。前面这些知识对我来说是非常宝贵的财富,可以说我能进淘宝,很大程度上也是因为我学习了前面这些知识的原因。

在介绍我设计的框架之前,我想先探讨一下以往我们都是如何思考设计OO的系统的。大家都知道,真正的对象应该是不仅有属性,而且有行为的。并且大家也有另外一个共识,那就是为了完成某个任务,各个对象应该会相互协作共同完成这个任务。之前我们在设计一个系统时,往往会先设计好各个对象,明确他们的职责,在这个过程中,还会考虑如何建立对象之间的关系(依赖、关联、聚合、组合),在这些关系的影响下,我们会认为对象之间应该有主从关系、依赖关系,等等。然后我们所做的这些设计最终的目的是为了能让对象之间能够通过相互协作来共同完成某个任务。这种方式最核心的设计特色是,我们会通过”对象引用“的方式来实现对象之间的各种关系。这种方式很好,并且我们也已经完全习惯了从对象的职责以及它们之间的关系的角度去设计对象。但这仅仅体现了一个哲学思想,那就是“物体之间通过直接作用完成某个任务”。

我觉得任何两个对象之间的交互有两种形式:1)直接作用,即对象A引用一个对象B,然后A调用B提供的某个方法,以此来完成两个对象之间的协作;2)间接作用,对象A不引用对象B,仅仅包含了一个对象B的唯一标识,当它要和对象B协作时,会发送一个消息给对象B,然后对象B收到该消息后做出响应,从而实现两个对象之间的协作;不管是哪种方式,他们最终的效果是一致的,都可以实现两个对象之间的交互并最终完成某个任务。那么这两种方式各自的优缺点在哪里呢?我个人觉得对于对象引用的方式,其好处就是简单、直观、容易理解,很符合我们平时的设计习惯。但坏处是什么呢?我个人觉得这种方式是形成对象耦合的根本原因,对象A对对象B存在了紧密的耦合,也许你会说,在间接作用的方式下,对象A不也会保留一个对象B的唯一标识吗?没错,但要知道保留引用和保留唯一标识的耦合强度是不一样的。前者的耦合强度更大,因为持有另外一个对象的引用就意味着可以直接操作该对象,https://www.wendangku.net/doc/2b6525494.html,而仅仅持有另外一个对象的唯一标识则不行,必须先根据该唯一标识获取另外一个对象,然后再操作它。而对于发送接受消息的方式,它的好处和坏处是什么呢?其实正好和前者相反,即不简单、不直观、不容易理解,容易让大家觉得有过度设计的嫌疑,而好处则是能够将两个对象之间的耦合度降到最低。

好了,有了前面这些介绍之后,我想可以引出我所设计的这个框架的设计思想了。

既然在对象直接作用的思路下设计软件的各种原则、模式,以及各种最佳实践已经很多了,如SOLID五大设计原则、GRASP九大OO设计原则、Gof的23种设计模式、各种更大的模式如MVC、MVP、MVVM,等等。所以,我也就不用去费功夫去研究了,直接利用前辈的研究成果就行了。但我发现在对象间接作用的思路下设计软件的各种原则或框架似乎还不够多。当然也有很多大家都很熟悉了,比如Observer设计模式,按照这个设计模式设计出

来的.NET框架中的事件和委托的机制,还有比如一些第三方的开源框架如事件总线,事件驱动架构,等等。

思考到这里,再结合自己最近不断学习DDD的背景下,我脑子里有了一个奇特的想法!那就是:是否可以搞一个事件驱动的领域模型实现框架从而可以让我们从消息和行为的角度去设计对象呢?

有了这个框架,我们可以:1)通过消息实现领域模型中各个领域对象之间的交互,或者说是通信及协作;2)通过消息实现领域模型和外界的交互,如领域模型的使用者和领域模型之间的交互,一般这个使用者是应用层;还有比如领域模型和数据持久层的交互。带着这个问题,我试图去寻找目前已有的框架来实现我的想法,但遗憾的是,我找不到,所以只能自己开发。想到这里,我其实挺担心的,因为我很有可能已经走火入魔了,因为我要走的设计道路很可能是个死胡同或不归路,或者说不是一条真正能很好的解决软件设计的路,不然我怎么会找不到这样的框架呢?但不管怎样,还是先试试再说吧!反正我的大脑放在那里不用也是浪费。就这样,带着这样的目标和思路,我开始一步步设计我的框架了。

经过了三个月的设计、编码、测试、分享、讨论、重构的循环过程。到目前为止,总算初步实现了自己当初的目标,现在唯一差的就是在真正的实际项目中使用了。但幸好已经写了两个不同层次的Demo用来验证我的框架了。

该Demo包含了框架的源代码和Demo文件,基于VS2010开发,因为需要用到.NET4.0中的一些特性,如逆变和协变。源代码打开后,EventBasedDDDExample.PresentationLayer 是启动项目,直接F5就可以运行。该Demo为了重点突出领域模型的设计,特意采用内存作为数据持久层,去掉了应用层,并且用控制台应用程序作为UI层,这样就方便大家运行Demo。该项目包含了四个演示的例子,前面两个例子演示了如何利用我的框架实现特定的业务场景(一个是银行转账的例子,另一个是论坛中发帖发回复删除回复的例子)。

该Demo是一个比较真实的项目,也是用VS2010开发。前身是我之前开发过的一个蜘蛛侠论坛,现在用我最新的框架来实现这个论坛。但由于时间有限,UI层还没开发好,但应用层、领域层、持久层已经开发好。因此大家在查看源代码时,不要去看UI层的设计,因为我还没开发好。https://www.wendangku.net/doc/2b6525494.html,而应该去看其他几层的设计!大家从我这个Demo中,可以看到如何将经典的领域驱动四层分层架构和我的框架集成。相信这对大家非常具有实用价值。然后关于项目的命名空间,我也要解释下。假设现在有一个公司要做一个项目,我觉得比较好的项目命名方式为:以CompanyName.ProductName作为前缀,基础类库命名为Common,产品中的某个子应用模块,则可以命名为

CompanyName.ProductName.Modules.Forum,

CompanyName.ProductName.Modules.Blog,等。然后每个模块还可以根据模块的分层设计分出不同的Project,比如论坛的应用层可以命名为:

CompanyName.ProductName.Modules.Forum.ApplicationService,等。由于我做的只是一个展示架构的Demo,所以没有用具体的CompanyName,ProductName。我觉得在开发阶段我们可以不使用最后的名字,到了最后项目快完成时再做统一全局替换即可。

下面介绍一下我的框架的设计思想:

领域模型的组成元素:领域服务(Domain Service)+领域对象(Domain Object)+领域事件(Domain Event)+中央事件处理器(Event Processer)。

1.领域服务:这个元素和Evans提到的领域服务一致,主要目的也是用来完成单个领

域对象不能完成的职责,如银行转账操作;

2.领域对象:这个元素和Evans提到的Entity很类似,也有一个唯一标识,但和Evans

中的概念也有不同的地方。比如Evans中的Entity为了保持领域模型的完整性,有聚合的概念,即Aggregate。另外还有值对象的概念,即Value Object。但在我的设计中,领域模型中的所有的对象都是平等的,没有任何聚合或关联的概念,也没有值对象的概念。所有的领域对象都通过事件来进行交互协作,从而达到完成各种任务的目的。

3.领域事件:这个元素在整个领域模型中最重要,就好比是人体的血液或神经。它是

领域模型内部各个领域对象之间通信以及领域模型和外部通信时传递的信息的载

体。通过领域事件,我们可以“串”连任何两个领域对象,从而达到让他们相互协作

的目的。所谓的串联就是,一个对象发出消息,另外一个对象接收消息并做出正确响应。值得一提的是,我这里提到的事件不仅仅是通知别人发生了什么,而是泛指所有可能的通信情况。比如告诉别人我要什么(我想干什么),告诉别人我将要做什么,等等。也就是说,事件有可能带有一定的目的性,即有可能会指定应该由哪个对象去响应该事件。也许在你看来这已经不是标准的事件了,因为标准的事件应

该是不可能知道会由哪些人回去响应该事件的。没错,它就是一个不标准的事件。

我前面已经提到了,我这里的事件指对象之间通信的载体。而通信的情况是非常多的,肯定不只局限于告诉别人我发生了什么,还有非常多其他的情况。最后还有一点需要特别指出的是,事件发出去并响应后,有可能会有响应结果。关于这个问题,一般有两个实现方式:利用事件的回调函数实现;让事件响应函数提供返回值,然后在事件完全响应完成后,从事件对象中取出可能的返回值。我认为这两种方式都可以,我的框架采用的是后者。

4.中央事件处理器:这个元素只做一件事情,那就是处理某个传进来的事件。怎么处

理?就是根据当前事件获取所有可能的响应者,然后调用每个响应者的响应函数执行每个响应。

另外,领域模型与外界如何交互呢?还是通过上面所提到的事件,当外界需要领域模型做什么事情时,就发送一个在领域模型中已经定义好的事件,然后领域模型或其他人(比如持久层)就会响应该事件了。当领域模型发生了什么或想要外界提供什么数据时,也是通过发送事件,然后外界就会响应,从而为领域模型提供必要的支持,如持久化支持。通过上面的分析,似乎可以看出我们已经找到银弹了,即找到了一种单一的模式可以用来解决所有的对象交互与协作的问题了?应该不是这样,但我自己没发现不知道这种设计的问题出在哪里,所以非常期望大家能多给我些意见。还是那句话,我希望我们每个中国人都是一个不盲目相信权威并敢于怀疑权威并能积极去思考和将自己的思考转化为生产力的人,而不只是一个仅仅会使用外国人写出来的框架的人。

这篇文章说的全部是思想或思考心得,接下来我会具体分析我上面提到的两个Demo的具体设计。但我真的很希望大家能重视思想,重视自己的思考过程,并且要敢于去将自己的思

想转化为具体的成果,如框架。我们来这个地球上走一趟,如果仅仅只是会用别人写出来的东西,那不是很可惜?但如果你根据自己的思想写出了几个能让别人用的东西出来,那不是非常好吗?那才是很有意义和价值的事情。

私募基金八大策略介绍

私募基金八大策略介绍 私募基金在国际金融市场上发展十分快速,并已占据十分重要的位置,几乎所有国际知名的金融控股公司都从事私募基金管理业务,同时也培育出了像索罗斯、巴菲特这样的投资大鳄。 而国内私募基金也驶入快车道,据中国基金业协会发布的最新数据显示,2016年4月,已登记私募基金管理人26045家;已备案私募基金31347只。国内的私募江湖也人才辈出,在这个战场里,我们见识过王亚伟、徐翔、刘世强、葛卫东、杨海等江山豪杰。 由于私募基金的信息透明度不高,其资金运作和收益状况,都不是公开进行的,投资者往往误认为私募基金运作风险大于收益。其实,私募基金成立时,都会选择稳定可靠、信誉好的合伙人,这点就迫使私募基金运作较为谨慎,自律加上内压式的管理模式,有利于规避风险,同时减少监管带来的巨大成本;而且,私募基金操作的高度灵活性和持仓品种的多样化,往往能抢得市场先机,赢得主动,使创造高额收益成为可能。 私募阳光化一直在曲折中艰难推进,直到2013年6月1日新《基金法》正式实施,把私募基金正式纳入监管范畴;2014年1月17日,基金业协会发布《私募投资基金管理人登记和基金备案办法(试行)》,私募行业的实质性监管政策才得以落地。 随着私募基金蓬勃发展,投资策略也逐渐多样化,基金投资策略可谓是百花齐放。为方便投资者更清晰的理解,经过精细梳理对目前私募行业所有的投资策略进行了细化,按投资策略分类主要分为:股票策略、事件驱动、管理期货、相对价值、宏观策略、债券基金、组合基金、复合策略等主要策略分类。以下将对各类型策略进行详细阐述。 股票策略 股票策略以股票为主要投资标的,是目前国内阳光私募行业最主流的投资策略,约有8成以上的私募基金采用该策略,内含股票多头、股票多空、股票市场中性三种子策略。目前国内的私募基金运作最多的投资策略即为股票策略。 1、股票多头

杨永兴:事件驱动交易策略

杨永兴:事件驱动交易策略(2012-10-28 13:22:19) 核心提示:成绩如此出色,少年私募英雄杨永兴究竟掌握了什么制胜法宝?4月2日,《每日经济新闻》专访了策略大师基金的管理团队,证通天下董事长杨永兴、证通天下总经理李世勇(以下统称为"策略大师")向记者透露了他们的宝贵经验。 在股市中把600万元变成一个亿,需要多少时间?有人会说5年、10年,也许更长,但有人只花了10个月。 在2007年朝阳永续的实盘大赛中,硅谷基金的投资经理杨永兴以高达1497%的收益率,完成了这个看似不可能完成的任务,其成绩远远超过当时参加评比的其他阳光私募和券商集合理财。当时,他只有25岁。 2009年3月2日,杨永兴再次带领他的团队扬帆起航,在重庆国投发行了一款名为"策略大师"的阳光私募信托计划。3月27日,经过短短20个交易日的运作,策略大师的单位净值已从1元猛增到1.467元,收益率高达46.7%,再次上演不可能完成的任务。成绩如此出色,少年私募英雄杨永兴究竟掌握了什么制胜法宝?4月2日,《每日经济新闻》专访了策略大师基金的管理团队,证通天下董事长杨永兴、证通天下总经理李世勇(以下统称为"策略大师")向记者透露了他们的宝贵经验。

制胜法宝快进快出只参与上涨趋势 NBD:你的阳光私募基金自3月2日成立以来,获取了46%的收益,成为2009年私募界的第一名。获胜的法宝是什么? 策略大师:我们最大的优势在于极强的风险控制意识和把握短期趋势的能力。首先,我们在投资前想的第一件事就是此次投资最大的风险在哪里?可能会有多大的亏损?有什么应对措施?在做好了最充分的准备之后,我们才会开始考虑潜在收益等因素。正是这种保守的风格,让策略大师的研究团队充分规避了2008年熊市的风险。其次,策略大师研究团队对中短期趋势的判断能力要远远强于对中长期趋势的判断。 当前中国A股市场游资和散户的力量相当强大,它们的交易偏好以及反映在盘面上的特征都很有规律,充分认识并利用这些规律,只参与其中风险最小、利润最大的几个时间阶段,就有可能实现持续复利。在操作上,我们基本不参与盘整和下跌,我们只参与上涨趋势。 NBD:策略大师主要的操作风格是快进快出、短线为主,在操作上具体有什么特点?

面向对象设计之定义领域服务

面向对象设计之定义领域服务 若遵循基于面向对象设计范式的领域驱动设计,并用以应对纷繁复杂的业务逻辑,则强调领域模型的充血设计模型已成为社区不争事实。我将Eric提及的战术设计要素如EnTIty、Value Object、Domain Service、Aggregate、Repository与Factory视为设计模型。这其中,只有EnTIty、Value Object和Domain Service才能表达领域逻辑。 为避免贫血模型,在封装领域逻辑时,考虑设计要素的顺序为: Value Object -》EnTIty -》Domain Service 切记,我们必须将Domain Service作为承担业务逻辑的最后的救命稻草。之所以把Domain Service放在最后,是因为我太清楚领域服务的强大魔力了。开发人员总会有一种惰性,很多时候不愿意仔细思考所谓职责(封装领域逻辑的行为)的正确履行者,而领域服务恰恰是最便捷的选择。 就我个人的理解,只有满足如下三个特征的领域行为才应该放到领域服务中: 领域行为需要多个领域实体参与协作 领域行为与状态无关 领域行为需要与外部资源(尤其是DB)协作 假设某系统的合同管理功能允许客户输入自编码,该自编码需要遵循一定的编码格式。在创建新合同时,客户输入自编码,系统需要检测该自编码是否在已有合同中已经存在。针对该需求,可以提炼出两个领域行为: 验证输入的自编码是否符合业务规则 检查自编码是否重复 在寻找职责的履行者时,我们应首先遵循信息专家模式,即拥有信息的对象就是操作该信息的专家,因此可以提出一个问题:领域行为要操作的数据由谁拥有?针对第一个领域行为,就是要确认谁拥有自编码格式的验证规则?有两个候选: 拥有自编码信息的合同(Contract)对象

2021年事件驱动策略的因子化特征之欧阳学文创编

事件驱动策略的因子化特征 欧阳光明(2021.03.07) 2016-05-30 16:01:00 1. 引言 本篇报告旨在对若干类事件进行综合量化分析,使投资者更加深入的理解不同事件的发生对股票价格的影响。在此基础上,我们将构造基于多事件驱动的组合投资策略。本篇报告的最后一部分,我们将事件驱动策略与多因子策略在组合权重优化的框架下相结合,构建了基于多因子多事件驱动的最优中性投资组合。实证结果表明,增加了事件驱动后的多因子组合,收益显著提升。 事件驱动研究的本质问题在于事件发生是否会产生超额收益或亏损?若能产生,该收益是否可持续存在?对于该问题的解答不仅有利于我们构建事件驱动选股策略,更重要的是使得投资者了解事件信息对股票价格运行所产生的影响,进而更深入的理解股票价格波动的成因。 我们利用风险模型对个股收益的分解,定义了事件异常收益AR (Abnormal Return),并根据不同事件对个股异常收益的影响,对事件属性进行了分类。在此基础上,我们构建了基于多事件驱动的组合投资策略。实证结果表明,组合收益稳健有效,在过去6年时间内均可稳定战胜基准指数。 事件驱动研究的本质仍然是对市场参与者内心预期、相互博弈的投资心理研究。本篇报告通过数据建模等方法,对事件影响进行了一定的统计观察。但模型终究只是研究工具,最终我们希望通过事件研究,使得投资者更深入的理解股票价格运行的成因及规律,进而达到无招胜有招之最高境界。 2. 异常收益 2.1 异常收益定义

从逻辑上而言,我们通常会研究事件发生前后,股票价格收益的分布情况,进而判断事件对股价的影响。但是,由于股票价格的波动受各种不同的风险因素影响,因此简单的利用收益率或者超额收益很难分辨出事件本身对股票价格所产生的影响。 我们通常利用异常收益来检验事件发生对股票价格所产生的影响。所谓事件异常收益指的是:在事件发生前后,股票收益率中,无法用市场、行业、风格所解释的收益部分称为异常收益。 风险模型对股票收益的分解为事件研究提供了较大的便利,通过统计事件发生前后,股票收益中无法利用已知因子所解释的部分,即特质收益项,就可以观察事件发生所导致的股票价格异常收益,即: 换言之,我们利用风险模型回归方程中的残差项作为事件发生窗口期内的股票异常收益,由于残差部分不包含任意行业与风格收益,因此可以纯粹的反映事件本身对股票价格的影响,这与我们定义异常收益的初衷思路是一致的。 并且,由于A股市场的公司事件往往多发生于中小创的股票,而这类股票在规模因子的驱动下,具有显著的风格收益,所以利用风险模型剔除风格收益的影响,完整的剥离出股票价格的异常收益,显得尤为重要。 2.2 事件核心逻辑 在定义了异常收益后,我们就可以对各类事件发生前后,个股异常收益的分布特征进行观察统计。我们首先给出事件驱动异常收益显著性统计的一般流程: Step1: 定义事件逻辑,统计事件(公告)发生时间点; Step2: 统计事件发生前后股票收益率,计算对应行业因子及风格因子; Step3: 根据风险模型回归方程,计算事件发生前后个股异常收益CAR; Step4: 计算事件发生全部个股异常收益AR均值;

领域驱动设计(DDD)架构的实践

领域驱动设计(DDD)架构的实践

前言 至少30年以前,一些软件设计人员就已经意识到领域建模和设计的重要性,并形成一种思潮,Eric Evans将其定义为领域驱动设计(Domain-Driven Design,简称DDD)。在互联网开发“小步快跑,迭代试错”的大环境下,DDD似乎是一种比较“古老而缓慢”的思想。 然而,由于互联网公司也逐渐深入实体经济,业务日益复杂,我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。本文就先来讲一下这些问题,然后再尝试在实践中用DDD的思想来解决这些问题。 问题 过度耦合 业务初期,我们的功能大都非常简单,普通的CRUD就能满足,此时系统是清晰的。随着迭代的不断演化,业务逻辑变得越来越复杂,我们的系统也越来越冗杂。模块彼此关联,谁都很难说清模块的具体功能意图是啥。修改一个功能时,往往光回溯该功能需要的修改点就需要很长时间,更别提修改带来的不可预知的影响面。

下图是一个常见的系统耦合病例。 订单服务接口中提供了查询、创建订单相关的接口,也提供了订单评价、支付、保险的接口。同时我们的表也是一个订单大表,包含了非常多字段。在我们维护代码时,牵一发而动全身,很可能只是想改下评价相关的功能,却影响到了创单核心路径。虽然我们可以通过测试保证功能完备性,但当我们在订单领域有大量需求同时并行开发时,改动重叠、恶性循环、疲于奔命修改各种问题。 上述问题,归根到底在于系统架构不清晰,划分出来的模块内聚度低、高耦合。

有一种解决方案,按照演进式设计的理论,让系统的设计随着系统实现的增长而增长。我们不需要作提前设计,就让系统伴随业务成长而演进。这当然是可行的,敏捷实践中的重构、测试驱动设计及持续集成可以对付各种混乱问题。重构——保持行为不变的代码改善清除了不协调的局部设计,测试驱动设计确保对系统的更改不会导致系统丢失或破坏现有功能,持续集成则为团队提供了同一代码库。 在这三种实践中,重构是克服演进式设计中大杂烩问题的主力,通过在单独的类及方法级别上做一系列小步重构来完成。我们可以很容易重构出一个独立的类来放某些通用的逻辑,但是你会发现你很难给它一个业务上的含义,只能给予一个技术维度描绘的含义。这会带来什么问题呢?新同学并不总是知道对通用逻辑的改动或获取来自该类。显然,制定项目规范并不是好的idea。我们又闻到了代码即将腐败的味道。 事实上,你可能意识到问题之所在。在解决现实问题时,我们会将问题映射到脑海中的概念模型,在模型中解决问题,再将解决方案转换为实际的代码。上述问题在于我们解决了设计到代码之间的重构,但提炼出来的设计模型,并不具有实际的业务含义,这就导致在开发新需求时,其他同学并不能很自然地将业务问题映射到该设计模型。设计似乎变成了重构者的自娱自乐,代码继续腐败,重新重构……无休止的循环。 用DDD则可以很好地解决领域模型到设计模型的同步、演化,最后再将反映了领域的设计模型转为实际的代码。

[教程]-领域驱动设计(DDD)

本文内容提要: 1. 领域驱动设计之领域模型 2. 为什么建立一个领域模型是重要的 3. 领域通用语言(Ubiquitous Language) 4.将领域模型转换为代码实现的最佳实践 5. 领域建模时思考问题的角度 6.领域驱动设计的标准分层架构 7. 领域驱动设计过程中使用的模式 关联的设计 实体(Entity) 值对象(Value Object) 领域服务(Domain Service) 聚合及聚合根(Aggregate,Aggregate Root) 工厂(Factory) 仓储(Repository) 8. 设计领域模型的一般步骤 9. 领域驱动设计的其他一些主题 10. 一些相关的扩展阅读 领域驱动设计之领域模型 2004年Eric Evans发表Domain-Driven Design – Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。领域驱动设计分为两个阶段: 1. 以一种领域专家、设计人员、开发人员都能理解的―通用语言‖作为相互交流的工具,在不断交流的过程中不断发现一些主要的领域概念,然后将这些概念设计成一个领域模型; 2. 由领域模型驱动软件设计,用代码来表现该领域模型。 由此可见,领域驱动设计的核心是建立领域模型。领域模型在软件架构中处于核心地位;软件开发过程中,必须以建立领域模型为中心。 为什么建立一个领域模型是重要的 领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点: 1. 领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分;

领域知识模型

领域知识模型——企业应用系统的智慧中枢 摘要:企业应用系统有海量的领域对象和丰富的领域知识,这些领域知识一般被作为领域对象的业务逻辑或规则定义。本文认为领域知识是领域模型的一个知识切面且自成体系,结合领域驱动设计[DDD]和面向方面编程[AOP]的方法,对领域知识进行建模和应用,让面向业务活动的领域应用对象只需关注业务过程的组织和管理,用AOP技术把领域知识应用到具体的业务处理策略中,使领域应用对象和领域知识对象有更好内聚性且更轻量,不仅可大幅提升它们的可管理性和复用性,而且对系统开发效率、动态业务建模和装配能力也大有益处。 关键词:领域知识、领域模型、领域驱动设计、企业应用架构、DDD、AOP 1.前言 领域模型[Domain Model]和领域驱动设计[Domain-Driven Design][1]是目前在应用软件行业非常热门和前沿的话题,普遍认为这是构建高质量复杂系统最有效的方法和技术。领域模型在业界比较认可的定义是:领域模型是领域内的概念或者现实世界中对象的可视化表示,又称为概念模型、领域对象模型、分析对象模型,它专注于分析领域问题本身,领域对象是与技术无关的纯业务对象。领域建模的核心理念是把业务对象的属性、规则和职能封装在领域对象中,而不是被分散在用户界面层、应用层和持久化层中。 领域建模一般情况下是从应用功能或用例[Use Case]入手,因此,领域模型中的领域对象也是直接与应用功能或用例相关的业务对象,而这些领域对象模型涉及的领域知识,一般都作为领域对象的逻辑或者规则而存在。知识是应用领域问题的本质,是特定领域中一系列业务对象共有的知识切面,这个知识切面自成体系,本文中把这个知识体系的模型称为领域知识模型,与具体应用功能或者活动相关的领域对象模型称为领域应用模型。为了便于理解这些概念,我用一个与企业管理无关的通俗的例子来说明知识模型和应用模型的关系,比如对我喜欢的台球运动进行游戏建模,美式九球模型或者英式斯诺克模型是具体的领域应用模型,球台、球、球杆、运动员等是应用领域模型的核心领域对象,但要做出好玩的仿真游戏,台球碰撞中的基本物理知识是不可或缺的,用牛顿理论作为领域知识模型就涉及到质量、速度、动量等概念和动量守恒及能量守恒模型。知识模型是高度抽象并且可独立存在的模型,也是可以在各种业务情景中复用的模型,就如前面提到的台球游戏用到的牛顿理论模型,同样可以应用到保龄球游戏以及任何一款涉及到碰撞的游戏场景。企业管理领域也同样存在大量的知识模型,本文笔者致力于把企业管理领域涉及的领域知识进行分离、建模和应用的可行性分析和实践,希望以此进一步提升大型复杂企业应用系统的质量、动态业务建模和装配能力及组件复用水平。 2.企业应用系统中的领域知识问题分析 企业应用系统已逐渐成为企业经营管理的一体化应用平台,面向业务流程的行业深度应用

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

?领域驱动设计之领域模型 ?为什么建立一个领域模型是重要的 ?领域通用语言(UBIQUITOUS LANGUAGE) ?将领域模型转换为代码实现的最佳实践 ?领域建模时思考问题的角度 ?领域驱动设计的经典分层架构 ?用户界面/展现层 ?应用层 ?领域层 ?基础设施层 ?领域驱动设计过程中使用的模式 ?所有模式的总揽图 ?关联的设计 ?实体(Entity) ?值对象(Value Object) ?领域服务(Domain Service) ?应用层服务 ?领域层服务 ?基础层服务 ?聚合及聚合根(Aggregate,Aggregate Root) ?聚合有以下一些特点: ?如何识别聚合? ?如何识别聚合根? ?工厂(Factory) ?仓储(Repository) ?设计领域模型的一般步骤 ?在分层架构中其他层如何与领域层交互 ?对于会影响领域层中领域对象状态的应用层功能 ?关于Unit of Work(工作单元)的几种实现方法 ?对于不会影响领域层中领域对象状态的查询功能 ?为什么面向对象比面向过程更能适应业务变化 ?领域驱动设计的其他一些主题 ?一些相关的扩展阅读 ?CQRS架构 ?Event Sourcing(事件溯源) ?DCI架构 ?四色原型分析模式 ?时刻-时间段原型(Moment-Interval Archetype) ?参与方-地点-物品原型(Part-Place-Thing Archetype)?描述原型(Description Archetype) ?角色原型(Role Archetype) 领域驱动设计之领域模型

加一个导航,关于如何设计聚合的详细思考,见这篇文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。领域驱动设计分为两个阶段: 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型; 由领域模型驱动软件设计,用代码来实现该领域模型; 由此可见,领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的 领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点: 1.领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领 域模型是有边界的,只反应了我们在领域内所关注的部分; 2.领域模型只反映业务,和任何技术实现无关;领域模型不仅能反映领域中的一些实体概 念,如货物,书本,应聘记录,地址,等;还能反映领域中的一些过程概念,如资金转 账,等; 3.领域模型确保了我们的软件的业务逻辑都在一个模型中,都在一个地方;这样对提高软 件的可维护性,业务可理解性以及可重用性方面都有很好的帮助; 4.领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造; 5.领域模型贯穿软件分析、设计,以及开发的整个过程;领域专家、设计人员、开发人员 通过领域模型进行交流,彼此共享知识与信息;因为大家面向的都是同一个模型,所以 可以防止需求走样,可以让软件设计开发人员做出来的软件真正满足需求; 6.要建立正确的领域模型并不简单,需要领域专家、设计、开发人员积极沟通共同努力, 然后才能使大家对领域的认识不断深入,从而不断细化和完善领域模型; 7.为了让领域模型看的见,我们需要用一些方法来表示它;图是表达领域模型最常用的方 式,但不是唯一的表达方式,代码或文字描述也能表达领域模型; 8.领域模型是整个软件的核心,是软件中最有价值和最具竞争力的部分;设计足够精良且 符合业务需求的领域模型能够更快速的响应需求变化; 领域通用语言(UBIQUITOUS LANGUAGE) 我们认识到由软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的,但是,那种方法通常会由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式、架构,等等,总是想将实际生活中的概念和程序工件进行对应。他们希望看到要建立哪些对象类,要如何对对象类之间的关系建模。他们会习惯按照封装、继承、多态等面向对象编程中的概念去思考,会随时随地这样交谈,这对他们来说这太正常不过了,开发人员就是开发人员。但是领域专家通常对这一无所知,他们对软件类库、框架、持久化甚至数据库没有什么概念。他们只了解他们特有的领域专业技能。比如,在空中交通监控样例中,领域专家知道飞机、路线、海拔、经度、纬度,知道飞机偏离了正常路线,知道飞机的发射。他们用他们自己的术语讨论这些事情,

《领域驱动设计》基础知识汇总

《领域驱动设计》基础知识汇总(转) 1. 什么是领域(Domain) 我们所做的软件系统的目的都是来解决一系列问题,例如做一个电商系统来在线销售自己 企业的产品;做一个灰度发布平台来提升服务的质量和稳定性。任何一个系统都会属于某 个特定的领域,例如: ?论坛是一个领域:要做一个论坛,那这个论坛的核心业务是确定的:比如用户发帖、回 帖等核心基本功能; ?电商系统是一个领域:只要是电商领域的系统,那核心业务就是:商品浏览、购物车、 下单、减库存、付款交易等核心环节; 同一个领域的系统都具有相同的核心业务,因为他们要解决的问题的本质是类似的。因此 可以推断:一个领域本质上可以理解为一个问题域。只要确定了系统所属的领域,那么这个系统的核心业务,即要解决的关键问题就基本确定了。通常我们说,要成为一个领域的 专家,必须要在这个领域深入研究很多年才行,只有这样才会遇到非常多的该领域的问题,积累了丰富的经验。 2.界限上下文(Bounded Context) 通常来说,一个领域有且只有一个核心问题,我们称之为该领域的『核心子域』。在核心 子域、通用子域、支撑子域梳理的同时,会定义出子域中的『限界上下文』及其关系,用 它来阐述子域之间的关系。界限上下文可以简单理解成一个子系统或组件模块。 例如:下图是对酒店管理的子域和界限上下文的梳理:

3. 领域模型(Domain Model) 领域驱动设计(Domain-Driven Design)分为两个阶段: 1.以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,在交 流的过程中发现领域概念,然后将这些概念设计成一个领域模型; 2.由领域模型驱动软件设计,用代码来实现该领域模型; 由此可见,领域驱动设计的核心是建立正确的领域模型。领域模型具有以下特点: 1.对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质。它属于『解 决问题空间』。领域模型是有边界的,只反应了我们在领域内所关注的部分,包括实体概 念(如:货物,书本,应聘记录,地址等),以及过程概念(如:资金转账等); 2.提高软件的可维护性,业务可理解性以及可重用性。领域模型确保了我们的软件的业 务逻辑都在一个模型中,帮助开发人员相对平滑地将领域知识转化为软件构造; 3.贯穿软件分析、设计、开发的整个过程。领域专家、设计人员、开发人员面向同一个 模型进行交流,彼此共享知识与信息,所以可以防止需求走样,让软件开发人员做出来的 软件真正满足需求;要建立正确的领域模型并不简单,需要领域专家、设计、开发人员积 极沟通共同努力,然后才能使大家对领域的认识不断深入,从而不断细化和完善领域模型; 4.为了让领域模型看的见,使用的常用表达领域模型的方式:图、代码或文字; 5.重要性:领域模型是整个软件的核心,是软件中最有价值和最具竞争力的部分;设计足 够精良且符合业务需求的领域模型能够更快速的响应需求变化; 4. 领域通用语言 由软件专家和领域专家合作开发一个领域的模型是有必要的。开发过程中,开发人员以类、算法、设计模式、架构等进行思考与交流。但领域专家对此一无所知,他们对技术上的术 语没有太多概念,只了解特有的领域专业技能,例如:在空中交通监控样例中,领域专家 知道飞机、路线、海拔、经度、纬度,他们有自己的术语来讨论这些事情。软件专家和领 域专家交流过程中,需要做翻译才能让对方理解这些概念。 领域驱动设计的一个核心原则是使用一种基于模型的语言。使用模型作为语言的核心骨架,要求团队在进行所有的交流是都使用一致的语言,在代码中也是这样,这种语言被称为 『通用语言』 5.建模思考的问题:用户需求 『用户需求』不能等同于『用户』,捕捉『用户心中的模型』也不能等同于『以用户为核 心设计领域模型』。设计领域模型时不能以用户为出发点去思考问题,不能老想着用户会 对系统做什么;而应该从一个客观的角度,根据用户需求挖掘出领域内的相关事物,思考 这些事物的本质关联及其变化规律作为出发点去思考问题。 领域模型是排除了人之外的客观世界模型,包含了人所扮演的参与者角色。但是一般情 况下不要让参与者角色在领域模型中占据主要位置,否则各个系统的领域模型将变得没有 差别,因为软件系统就是一个人机交互的系统,都是以人为主的活动记录或跟踪。例如:?论坛中如果以人为主导,那么领域模型就是:人发帖,人回帖,人结贴,等等; ?货物托运系统中如果以人为主导,就变成了:托运人托运货物,收货人收货物,付款人 付款,等等;

异常波动事件驱动策略量化研究

龙源期刊网 https://www.wendangku.net/doc/2b6525494.html, 异常波动事件驱动策略量化研究 作者:尚琳喆夏青桐 来源:《科学与财富》2020年第02期 摘要:异常波动事件是指上市公司在市场上发布股价异常波动公告的行为。从直观上讲,出现股价异常波动的股票可能存在获取超额收益的机会,本报告用量化的方法研究了出现股价异常波动的股票是否在后期存在获取超额收益的机会,发现异常波动事件对应公司股价存在一定超额收益。进一步我们构建了异常波动事件驱动选股策略,利用数据进行回测。 关键词:异常波动事件;事件驱动;超额收益;量化 一、异常波动事件综述 异常波动事件是指上市公司在市场上发布股价异常波动公告的行为。通常,某支股票股价在短期出现异常波动,原因可能有:公司经营情况和内外部经营环境发生重大变化、公司近期正在筹划重大事项和公共传媒报道了对公司股价产生影响的重大事件等。从直观上讲,出现股价异常波动的股票可能存在获取超额收益的机会。 1.1股价异常波动相关规定 股价异常波动,主要是为了规范股市,防止有人利用大量资金人为地在短期内操作股价。异常波动判定依据根据《上海证券交易所交易规则(2015年修订)》,主要指标为:收盘价 格涨跌幅偏离值、日均换手率和证监会规定其他情形。异常波动指标自复牌之日起重新计算。 当交易所察觉某只股票符合上述特征时,即要求上市公司做出示警声明,并就可能产生的原因做出说明,而交易所会在随后的一个交易日开市时对该股票实施停牌一小时。对于未能及时发布公告说明原因的股票,交易所会要求上市公司进行停牌自查,直到上市公司就异常波动做出说明并发布公告方可申请复牌。 1.2异常波动分布情况 我们将异常波动事件分为两类:发布异常波动公告后次日仍可以正常交易、发布异常波动公告后停牌一天及以上。我们从巨潮资讯爬取了沪深两市上市公司的所有股价异常波动公告,剔除冗余公告。统计区间为2002年1月1日到2017年7月4日,在此区间内共出现27320例股价异常波动事件,涉及到上市公司3272家。其中异常波动未停牌事件26258件,占事件总数的96.11%;异常波动停牌事件1062件,占事件总数的3.89%。

领域驱动设计和开发实战

领域驱动设计和开发实战 背景 领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中。大部分关于此主题的著作和文章都以Eric Evans的书《领域驱动设计》为基础,主要从概念和设计的角度探讨领域建模和设计情况。这些著作讨论实体、值对象、服务等DDD的主要内容,或者谈论通用语言、界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念。 本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它。我们将着眼于技术主管和架极师在实现过程中能用到的指导方针、最佳实践、框架及工具。领域驱动设计和开发也受一些架极、设计、实现方面的影响,比如: ?业务规则 ?持久化 ?缓存 ?事务管理 ?安全 ?代码生成 ?测试驱动开发 ?重构 本文讨论这些不同的因素在项目实施的整个生命周期中怎样对其产生影响,还有架极师在实现成功的DDD中应该去寻求什么。我会先列出领域模型应该具备的典型特征,以及何时在企业中使用领域模型(相对于根本不使用领域模型,或使用贫血的领域模型来说)。 文章包括一个贷款处理示例应用,来演示如何将设计立场、以及这里讨论的开发最佳实践,应用在真实的领域驱动开发项目之中。示例应用用了一些框架去实现贷款处理领域模型,比如Spring、Dozer、Spring Security、JAXB、Arid POJOs和Spring Dynamic Modules。示例代码用Java编写,但对大多数开发人员来说,不论语言背景如何,代码都是很容易理解的。 引言 领域模型带来了一些好处,其中有: ?有助于团队创建一个业务部门与IT部门都能理解的通用模型,并用该模型来沟通业务需求、数据实体、过程模型。 ?模型是模块化、可扩展、易于维护的,同时设计还反映了业务模型。 ?提高了业务领域对象的可重用性和可测性。 反过来,如果IT团队在开发大中型企业软件应用时不遵循领域模型方法,我们看看会发生些什么。 不投放资源去建立和开发领域模型,会导致应用架极出现“肥服务层”和“贫血的领域模型”,在这样的架极中,外观类(通常是无状态会话Bean)开始积聚越来越多的业务逻辑,而领域对象则成为只有getter和setter方法的数据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的外观类中(有些情况下还会出现重复的逻辑)。

在https://www.wendangku.net/doc/2b6525494.html,MVC4中使用领域驱动设计

在领域驱动设计中,我们首先会为领域设计模型,且在设计的过程中完全不考虑存储和具体的实现细节。也就是说在设计中,我们把数据库放在了一个次要的位置(其实仍然很重要,只是在设计架构时我们不考虑它)。有了模型以后,下一步就是如何持久化(保存数据),且这里就存在着面向对象方式表示的数据和数据库所使用的基于元组的关系模型之间的不一致(对象-关系阻抗失谐)。如果可以选用面向对象数据库,事情就会容易许多,然而面向对象数据库并没有成为IT界的主流,因此关系型数据库就成为你唯一的选择。之所以会出现基于领域的设计是为了处理真实世界中的复杂性。运用领域驱动设计之后,你要么选用面向对像数据库,要么引入一个O/R映射层。 然而实现领域驱动设计很复杂,甚至可以说以个人之力完全无法实现。幸好现在有很多框架可用,例如Entity Framework(以下简称EF)。使用EF有三种方法:1.数据库优先,即先设计数据库,然后做数据库和面向对象模型的映射;2.模型优先,先用EF自带的设计工具设计模型,然后生成sql脚本,创建数据库;3.代码优先,先使用其他UML工具设计模型,根据模型手动编写模型代码,然后生成sql脚本,创建数据库。目前最流行的是代码优先,因为它最灵活,然而代码优先的工作量很大。而数据库优先的方法和领域驱动设计的思想相悖。所以我选择了模型优先的方法,但在EF4中,使用模型优先是有问题的,它生成的模型都继承自一个名为EntityObject的基类,这个基类包含了访问数据库的方法,这就不支持持久化透明了。幸好在EF4.1以后微软引入了DbContext,用EF4.1的模型优先可以生成支持持久化透明的实体类,不继承任何基类,数据访问由DbContext实现。在VS2012中创建一个https://www.wendangku.net/doc/2b6525494.html, MVC4项目,VS2012会自动添加EF5.0的引用,并且在设计模型时会自动生成支持持久化透明的实体类,但在VS2010中要麻烦点,这里不做说明了,因为用了VS2012就完全没有问题了。具体建模过程不做介绍,网上一搜一大堆。下图为模型的一部分: 在传统的三层架构设计中,三层架构分为数据访问层、业务逻辑层和表现层。很多人在自己实现三层架构的时候都会明确的定义DAL、BLL和UI,但在实现的过程中总会有一些误解,例如很多人误把用户操作的流程当成业务逻辑,而数据访问层就是大量的sql语句和连接数据库的操作。实际上,用户的操作流程应该称为应用逻辑,应该放在服务层。我看过很多人设计的三层架构,BLL层几乎没有什么代码,只是简单的对DAL层的调用,复杂的数据访

量化对冲策略及产品简介-专题研究

“量化对冲”是“量化”和“对冲”两个概念的结合。“量化”指借助统计方法、数学模型来指导投资,其本质是定性投资的数量化实践。“对冲”指通过管理并降低组合系统风险以应对金融市场变化,获取相对稳定的收益。实际中对冲基金往往采用量化投资方法,两者经常交替使用,但量化基金不完全等同于对冲基金。 过去的13年间全球对冲基金市场经历了快速增长、衰退、反弹三个阶段。08年金融危机前,全球对冲基金规模由2000年的3350亿美元上升至1.95万亿美元。受金融危机影响,全球对冲基金规模一度缩减。09年之后,在全球经济复苏背景下对冲基金规模又开始反弹,截至2013年11月底,全球对冲共基金管理着1.99万亿美元的资产。 从目前对冲基金的全球分布来看,北美地区(美国为主)是全球对冲基金市场发展最成熟的地区,且近年来占比有所扩大,截止2013年11月该地区对冲基金规模占据全球的67.5%。其次是欧洲地区,占比达22.2%;接着是亚太地区,占比达7.3%(日本+亚洲非日本) 常见的量化对冲策略包括:股票对冲(Equity Hedge)、事件驱动(Event Driven)、全球宏观(Macro)、相对价值套利(Relative Value)四种,任意一只对冲基金既可采取其中某一策略也可同时采取多种投资策略,目前全球使用占比最高的策略是股票多空策略,占比达32.5% 量化对冲产品有以下几方面特点:1、投资范围广泛,投资策略灵活;2、无论市场上涨还是下跌,均以获取绝对收益为目标;3、更好的风险调整收益,长期中对冲基金在获取稳定收益的同时提供了更好的防御性;4、与主要市场指数相关性低,具备资产配置价值。 一、什么是量化对冲投资? 近年来随着证券市场不断发展,金融衍生产品不断推出,做空工具不断丰富,投资的复杂程度也日益提高,其中以追求绝对收益为目标的量化对冲投资策略以其风险低、收益稳定的特性,成为机构投资者的主要投资策略之一。 所谓“量化对冲”其实是“量化”和“对冲”两个概念的结合。 其中“量化”投资是区别于传统“定性”投资而言的。量化投资通过借助统计学、数学方法,运用计算机从海量历史数据中寻找能够带来超额收益的多种“大概率”策略,并纪律严明地按照这些策略所构建的数量化模型来指导投资,力求取得稳定的、可持续的、高于平均的超额回报,其本质是定性投资的数量化实践。由此可见,所有采用量化投资策略的产品(包括普通公募基金、对冲基金等等)都可以纳入量化基金的范畴。量化投资的最大的特点是强调纪律性,即可以克服投资者主观情绪的影响。

基于事件驱动的DDD领域驱动设计框架分享(附源代码)

基于事件驱动的DDD领域驱动设计框架分享(附源代码) 补充:现在再回过头来看这篇文章,感觉当初自己偏激了,呵呵。不过没有以前的我,怎么会有现在的我和现在的enode框架呢?发现自己进步了真好!从去年10月份开始,学了几个月的领域驱动设计(Domain Driven Design,简称DDD)。主要是学习领域驱动设计之父Eric Evans的名著:《Domain-driven design:领域驱动设计:软件核心复杂性应对之道》,以及另外一本Martin Flower的《企业应用架构模式》,学习到了不少关于如何组织业务逻辑方面的知识。另外,在这个过程中也接触到了一些开源的架构和一些很好的思想。如:命令查询职责分离(Command Query Responsibility Segregation,简称CQRS),事件驱动架构(Event Driven Architecture,简称EDA),以及四色原型和DCI架构,等等。前面这些知识对我来说是非常宝贵的财富,可以说我能进淘宝,很大程度上也是因为我学习了前面这些知识的原因。在介绍我设计的框架之前,我想先探讨一下以往我们都是如何思考设计OO的系统的。大家都知道,真正的对象应该是不仅有属性,而且有行为的。并且大家也有另外一个共识,那就是为了完成某个任务,各个对象应该会相互协作共同完成这个任务。之前我们在设计一个系统时,往往会先设计好各个对象,明确他们的职责,在这个过程中,

还会考虑如何建立对象之间的关系(依赖、关联、聚合、组合),在这些关系的影响下,我们会认为对象之间应该有主从关系、依赖关系,等等。然后我们所做的这些设计最终的目的是为了能让对象之间能够通过相互协作来共同完成某 个任务。这种方式最核心的设计特色是,我们会通过”对象引用“的方式来实现对象之间的各种关系。这种方式很好,并且我们也已经完全习惯了从对象的职责以及它们之间的关系 的角度去设计对象。但这仅仅体现了一个哲学思想,那就是“物体之间通过直接作用完成某个任务”。我觉得任何两个对象之间的交互有两种形式:1)直接作用,即对象A引用一个对象B,然后A调用B提供的某个方法,以此来完成两个对象之间的协作;2)间接作用,对象A不引用对象B,仅仅包含了一个对象B的唯一标识,当它要和对象B协作时,会发送一个消息给对象B,然后对象B收到该消息后做出响应,从而实现两个对象之间的协作;不管是哪种方式,他们最终的效果是一致的,都可以实现两个对象之间的交互并最终完成某个任务。那么这两种方式各自的优缺点在哪里呢?我个人觉得对于对象引用的方式,其好处就是简单、直观、容易理解,很符合我们平时的设计习惯。但坏处是什么呢?我个人觉得这种方式是形成对象耦合的根本原因,对象A对对象B存在了紧密的耦合,也许你会说,在间接作用的方式下,对象A不也会保留一个对象B的唯一标识吗?没错,但

事件驱动策略的因子化特征

事件驱动策略的因子化特征 2016-05-30 16:01:00 1. 引言 本篇报告旨在对若干类事件进行综合量化分析,使投资者更加深入的理解不 同事件的发生对股票价格的影响。在此基础上,我们将构造基于多事件驱动的组合投资策略。本篇报告的最后一部分,我们将事件驱动策略与多因子策略在组合权 重优化的框架下相结合,构建了基于多因子多事件驱动的最优中性投资组合。实证结果表明,增加了事件驱动后的多因子组合,收益显著提升。 事件驱动研究的本质问题在于事件发生是否会产生超额收益或亏损?若能产生,该收益是否可持续存在?对于该问题的解答不仅有利于我们构建事件驱动选股策略,

更重要的是使得投资者了解事件信息对股票价格运行所产生的影响,进而更深入的理解股票价格波动的成因。 我们利用风险模型对个股收益的分解,定义了事件异常收益AR(Abnormal Return),并根据不同事件对个股异常收益的影响,对事件属性进行了分类。在 此基础上,我们构建了基于多事件驱动的组合投资策略。实证结果表明,组合收 益稳健有效,在过去6年时间内均可稳定战胜基准指数。 事件驱动研究的本质仍然是对市场参与者内心预期、相互博弈的投资心理研究。本篇报告通过数据建模等方法,对事件影响进行了一定的统计观察。但模型终究只是研究工具,最终我们希望通过事件研究,使得投资者更深入的理解股票价 格运行的成因及规律,进而达到无招胜有招之最高境界。 2. 异常收益 2.1 异常收益定义 从逻辑上而言,我们通常会研究事件发生前后,股票价格收益的分布情况,进而判断事件对股价的影响。但是,由于股票价格的波动受各种不同的风险因素影响,因此简单的利用收益率或者超额收益很难分辨出事件本身对股票价格所产生的影响。 我们通常利用异常收益来检验事件发生对股票价格所产生的影响。所谓事件异常收益指的是:在事件发生前后,股票收益率中,无法用市场、行业、风格所解释的收益部分称为异常收益。 风险模型对股票收益的分解为事件研究提供了较大的便利,通过统计事件发生前后,股票收益中无法利用已知因子所解释的部分,即特质收益项,就可以观察事件发生所导致的股票价格异常收益,即:

事件驱动策略之四——ETF事件套利研究

ETF 事件套利研究 众所周知,跌停的股票很难卖出,涨停的股票很难买进,而停牌的股票更是没有办法进行交易。股票市场的变化总是超乎人们的预期,利空(好)消息放出,常常是多个跌(涨)停连续出现,而这时卖出(买入)相应的股票是很困难的,然而若相应的股票是ETF 的成分股,我们则可以变相买入(卖出)相应的股票。本文详细介绍了如何通过一、二级市场和融券机制买入(卖出)停牌(涨跌停)的股票,并对套利收益率进行了敏感性分析。 ● 跨市场套利。跨市场是指通过一、二级市场操作变相买卖停牌的股票。由于一般成分股在指数中的占比很有限,而在套利操作时涉及到大量其他成分股的买卖,交易成本很大,所以套利机会并不多见,以占指数权重1%的股票为例,复牌后涨幅40%或跌幅45%才能有套利正收益。 ● 利用融券机制套利。今年12月5日起,上证50、深证100等7只ETF 成为融券标的,我们可以通过卖空ETF 、买入股票或者买入ETF 、卖空股票来变相卖出、买入涨跌停的个股。和跨市场套利一样,利用融券套利的交易成本很大,套利机会也鲜有出现,以占指数权重1%的股票为例,5个涨停或7个跌停才能有套利正收益。● 由于事件套利的机会并不多见,当有重大事件发生时,我们会以快报的形式提醒投资者事件套利的机会(例如前期重庆啤酒连续跌停事件)。 定量研究 证券研究报告 专题报告

目录 1. 参数说明 (3) 2. 跨市场套利 (3) 2.1 买入停牌的股票 (3) 2.2 卖出停牌的股票 (4) 3. 利用融券机制套利 (5) 3.1 卖出跌停的股票 (5) 3.2 买入涨停的股票 (6)

众所周知,跌停的股票很难卖出,涨停的股票很难买进,而停牌的股票更是没有办 法进行交易。股票市场的变化总是超乎人们的预期,利空(好)消息放出,常常是多个跌(涨)停连续出现,而这时卖出(买入)相应的股票是很困难的,然而若相应的股票是ETF 的成分股,我们则可以变相买入(卖出)相应的股票。本文详细介绍了如何通过一、二级市场和融券机制买入(卖出)停牌(涨跌停)的股票,并对套利收益率进行了敏感性分析。 1. 参数说明 由于ETF 瞬时套利机制的存在,一、二级市场的折溢价很小,在以下的讨论中我们 均假设一、二级市场无折溢价。 1)ETF 买卖佣金——上交所3bp ,深交所4-5bp ,记为d1 2)股票、ETF 买卖冲击成本——10bp ,记为d2 3)股票买卖佣金——10bp ,记为d3 4)股票卖出印花税——10bp ,记为d4 5)融券年化利息——9.1%,按日利息2.5bp (9.1%/365)收取,记为d5 6)ETF 申购赎回费——不收取费用 7)融券保证金比例——50%,记为c 8)停牌(涨/跌停)股票占相应指数中的权重——记为w 9)ETF 中股票现金替代比例——10%,记为q 10)XX 股票在停牌(涨/跌停)期间的涨跌幅为r 11)操作时点XXETF 的最新参考净值为S 2. 跨市场套利 2.1 买入停牌的股票 情形一:XX 股票停牌(XX 股票是YYETF 成分股),预期复牌后股价将大涨,利用一、 二级市场买入停牌的XX 股票。 操作方法:在二级市场买入YYETF ,立刻在一级市场赎回YYETF ,取回相应的一篮子 股票,卖出除XX 股票以外的其他股票,保留XX 股票。 注意事项:若XX 股票“必须/允许现金替代”,那么赎回时基金公司可能将返还给XX 股票对应时点价格的现金,而无法得到XX 股票,导致套利无法完成。 则套利过程中涉及到的现金流有: 买入YYETF 需要资金S1: (112)S d d ?++ 赎回ETF ,卖出除XX 股票以外其他成分股获得资金S2: (1)(1234S w d d d ?-?---))卖出XX 股票获得资金S3: (1)(1234S w r d d d ??+?--- 套利收益率为: 231 S S S S 1 +- 带入公式简化后即: (1234)122112 w r d d d d d d d d 3 ??-----?-++ 按照我们设定的成本参数,得到套利收益率为: 997036 10013 w r ??-

相关文档
相关文档 最新文档