请问这种情况该怎么办好呢

10-06-12 madeby
现在我们有一个项目,客户端主要分为两类功能,一类是许多类似网站后台似的管理程序,主要是增删改查,感觉用bs更好,另一类是完成图像处理的功能,其交互复杂性和计算要求更适合采用CS程序,而且整套系统中数据流转时bs程序和cs程序有很多业务数据是相关的,需要公共访问的类、接口等。

这时问题就来了,Entity一般都不是贫血的,包含了很多业务方法,但这些方法依赖于service、specification、valueobject等等领域概念,而且有的方法会调用基础设施的,这些基础设施可能根本不在客户端上,那我们B端和C端都要访问Entity,就会出现有的方法能够调用,有的方法根本不应该调,这Entity简直没法设计...

而且持久化的时候repository又不应该直接暴露给每个客户端,因为对于每种Entity全局应该只有一个仓库,所以可能要把这部分功能用webservice等远程访问方式封装,怎么感觉是支离破碎的呢。。。

换过来如果采用贫血模型,c端写一些面向过程式的业务逻辑,访问Entity,然后调用服务端,让服务端的repository维护一下持久化,也不会因为调用Entity的方法访问根本不在本地的基础设施了,但这样一来B端又很郁闷,因为Entity都是贫血的。。。!那还怎么用DDD,岂不是要事务脚本了?

上一个项目是纯BS架构的,应用DDD还是不错的,虽然有些设计还比较幼稚,但还是比以往面向过程、面向DB的思路写出来的程序好,可读性、可维护性、可扩展性都好了。

这次这个项目不知道该怎么办了,难道要回到老路上去吗????

         

banq
2010-06-12 11:44
2010年06月12日 10:07 "madeby"的内容
这次这个项目不知道该怎么办了,难道要回到老路上去吗? ...

从现实角度来讲,还是用事务脚本+贫血模型+面向数据库编程没有风险,新的DDD编程思路不太适合重构,而是重写。架构基本就变掉了,而且这样做的好处只适合复杂 要持续多年维护拓展的系统。

madeby
2010-06-12 12:34
2010年06月12日 11:44 "banq"的内容
从现实角度来讲,还是用事务脚本+贫血模型+面向数据库编程没有风险,新的DDD编程思路不太适合重构,而是重写。架构基本就变掉了,而且这样做的好处只适合复杂 要持续多年维护拓展的系统。 ...

现在这个系统还在设计思考阶段,具体怎么实现得权衡以后做,不是已有系统,但我也是倾向于事务脚本+贫血模型+面向数据库了,不知道如果DDD能怎么做,会不会像我说的那样ugly...

banq
2010-06-12 15:37
2010年06月12日 10:07 "madeby"的内容
就会出现有的方法能够调用,有的方法根本不应该调,这Entity简直没法设计. ...

如果你把所有方法放到一个Entity类中才urly呢,这里就取决于你的OO分析设计能力,根据职责分离,通过引入DCI架构等等,关键是:Entity在运行时是扮演无所不能的全能对象,但是在编码阶段你不能将所有职责方法都编入一个Entity。

具体怎么做,可参考本站讨论,如:

DCI,领域模型,领域事件的一些想法

目前这个领域应该说是在创新探索,如果你乐观的话可以试验一下,悲观的就用老方法吧。

猜你喜欢