项目所属领域:基金领域
业务:申购基金、赎回基金、转换基金。
PPT:Fund(基金)
代码如下:
|
固有属性FundType(基金类型)
代码如下:
|
固有属性FundClass(基金种类)
代码如下:
|
固有属性FundCompany(基金所属公司)
代码如下:
|
[该贴被achilleswar于2011-05-12 08:38修改过]
|
|
|
|
|
|
|
|
|
|
|
我的感觉是否下面的架构:
应用层 -> 场景 -> 领域 ?? 各位讨论讨论。
不过我的场景里没有再进行角色的,而是场景中直接指导领域模型完成业务逻辑,我之所以没有抽取出角色是因为感觉有时候没有必要,因为逻辑如果不是很复杂,再抽象出角色,有点过度设计。
ps:另外 @liontseng 哥们说的问题也是我在思考的问题,到底有没有必要通过服务去封转场景呢?目前来说服务是静态的,无状态的,但是场景是有状态的,动态的,场景一般来说是每个请求过来创建出常见对象,然后完成业务逻辑,场景对象生命周期就结束了,而封装成服务可以更好的实现远程调用,比如一个分布式系统中,如果不通过服务封转场景的话,客户端代码可能就需要自己去创建场景,而场景的创建往往比较复杂(因为场景有很多不变量要满足,场景一当创建好了以后,就可以直接进行业务逻辑操作了,我目前的做法是场景专门的工厂对象来保证场景的不变量)。
因此如果业务操作逻辑需要进行远程调用的话,我建议通过服务暴漏粗粒度的接口给客户端使用,客户端不用关心太多细节,但是如果是本系统内部调用的话,场景可以直接使用。
也希望大家参与讨论讨论。
是的,实际做项目可以采取这种过渡式的架构,实际上,在理论上我在想,如果把场景前移到客户端也未必不是一种好方式,就象我们剧团下乡演出一样,因为我们现在已经可以使用DCI将演出场景的道具准备妥当,到时现场一搭建组装就可以。
为什么SOA把服务留在服务器端呢?因为技术限制,限制于Java这些静态型将类作为对象语言限制,不能将场景需要的角色行为 实体进行分离,必须吧角色行为静态地写到类中,作为其方法,而DCI可以是无方法角色,以及一些简单的领域对象,在客户端现场通过场景进行组装。
如果是这样,SOA真的可以死了,一枪毙命。哈哈,只是畅想。
呵呵,恩,认同,这我之前发过一个帖子http://xmuzyq.iteye.com/blog/975675,我们可以把场景打成客户端jar的形式丢到具体的客户端服务器去使用,目前有项目也采用这种方式,因为运算逻辑复杂,如果放在中心服务器端,中心服务器端会成为瓶颈,而前端的应用服务器压力小,所以将逻辑从中心节点转移到各个客户端节点,这点其实也使得系统伸缩性更好一点。当场景打包成jar放到客户度调用,只不过场景中可能需要调用其它的远程接口,而这种远程接口多数情况下是用来获取数据的。
这是一种方式,更优雅的可以通过消息或事件来驱动。