所在位置:答疑 - 内容   
领域模型的实现
 

2009-7-2  10:02:50  xu_zh:  领域模型是一个能够表达领域核心知识的模型对么?
2009-7-2  10:03:55  潘:  对的
2009-7-2  10:04:46  xu_zh:  是通过领域对象,对象属性,方法还有对象关系来表示吧?
2009-7-2  10:05:17  xu_zh:  领域模型和需求应该不是一个东西吧?
2009-7-2  10:05:46  xu_zh:  领域模型应该是软件架构的基础吧?
2009-7-2  10:05:46  潘:  就是类图序列图状态图
2009-7-2  10:06:35  潘:  需求指某个系统的需求,你做不做这个系统,或者怎么做,领域的概念是不会变化的
2009-7-2  10:07:09  潘:  比如林场里的种种关系,本来就在那里

2009-7-2  10:08:14  xu_zh:  领域模型是我们面对的客观世界的本质和抽象描述
2009-7-2  10:08:48  xu_zh:  领域模型应该是软件架构的基础吧?可以这么说吧 
2009-7-2  10:10:47  潘:  对的,以这个观点来做系统,就是所谓领域驱动设计。但实际上现在很多系统不是这么做的
2009-7-7  16:05:03  xu_zh:  潘老师,我按照彩色建模做好了一个收购林班模型,你帮我看看有没有什么问题
2009-7-7  16:05:30  潘:  好
2009-7-7  16:07:53  潘:  晚上回复你

2009-7-8  9:49:01  xu_zh:  潘老师你好,谢谢指教.对于角色上定义的方法,我是参考彩色建模这本书的,这本书中角色定义了方法,我猜测方法的实现可能是在红色时刻时段中,因为他们有相同方法名,这点我也不敢肯定
2009-7-8  9:58:14  xu_zh:  如果是我推测的这样,则在时刻时段中要加相同的"结算供应款"方法
2009-7-8  10:32:22  潘:  颜色只是辅助思考,不是很严格的。方法要尽量和类的资源匹配。
2009-7-8  10:34:03  xu_zh:  恩,谢谢
2009-9-17  15:03:11  xu_zh:  需求定义中我们定义了业务规则和系统做什么,业务规则应该要映射到领域模型中去吧?
2009-9-17  15:03:29  潘:  是的
2009-9-17  15:04:20  xu_zh:  还有就是系统做什么,属于系统功能定义的接口,如果这个功能是业务功能,那么他也要映射到领域模型中去吧?
2009-9-17  15:04:57  xu_zh:  领域模型相当于是这个接口的业务实现
2009-9-17  15:06:29  xu_zh:  譬如,确认入库后系统要1、改变库存,2、生成生产工资,这两个业务功能,应该在领域模型中表示出来,对吧?
2009-9-17  15:08:08  潘:  业务规则是系统外在表现的规律,例如,提前30 天付费,可以7 折,提前20 天付费,可以8 折.....映射到分析设计,会有一个类或几个类来封装该规则
2009-9-17  15:09:00  潘:  系统要1、改变库存,2、生成生产工资---这是"系统"要做的两件事情,但具体有哪些类来做,要通过分析来分配
2009-9-17  15:09:18  潘:  系统改变库存,系统生成生产工资--这个是需求

2009-9-17  15:09:43  xu_zh:  嗯,
2009-9-17  15:10:26  潘:  库存.改变库存(); 员工.计算生产工资();
2009-9-17  15:10:28  潘:  这是分析

2009-9-17  15:11:44  xu_zh:  领域模型中要体现这个分析的实现吧?
2009-9-17  15:11:53  潘:  要的
2009-9-17  15:12:04  潘:  特别是通过序列图来体现

2009-9-17  15:12:43  xu_zh:  那么可不可以说领域模型中实现的业务方法和业务规则,在需求中都有定义?
2009-9-17  15:13:30  潘:  对的,都有涉及,但不会定义清楚,例如,
2009-9-17  15:14:02  xu_zh:  不会有定义细节
2009-9-17  15:14:14  潘:  录入××单,里面有几十个字段,但哪些字段属于哪个类,如何分类,要靠自己想
2009-9-17  15:14:24  潘:  细节有,但是具体的细节
2009-9-17  15:14:43  潘:  而分析设计要从具体中抽象出本质来

2009-9-17  15:15:15  xu_zh:  恩
2009-9-17  15:15:58  潘:  例如,具体中有退货,购货,窜货.....,经分析,发现很多共同的特征,抽象出"货物流动事件"的概念,这个需求中是不会直接有的
2009-9-21  9:58:56  xu_zh:  我们目前常见的处理业务方法方式是在domain 中实现业务方法(譬如图书入库对应的stockin.java,stockindetail.java 中实现业务方法,同时这两个类也是hibernate 持久化类)。如果我们采用彩色建模在分析阶段我们有时刻时段类, 角色类, 参与方类和物品描述类( 假设时刻时段就是入库(Instock.java,InstockDetail.java);角色分已入库物品(StockedBook.java),待入库物品(UnstockedBook.java);参与方物品类(Book.java);物品描述类(BoolDesc.java))。现在如何实现有两种方法,一个是把我们分析的类的方法映射到( stockin.java,stockindetail.java ) 这两个类中, 在实现中去掉建模中的类; 第二个方法是
(stockin.java,stockindetail.java)这两
2009-9-21  10:00:08  xu_zh:  第二个方法是(stockin.java,stockindetail.java)这两个类只有基本get,set方法,不包含业务方法,他们只是持久化类,同时分析类也全部保留,在分析类和持久化类之间增加访问依赖,业务方法还保留在分析类中 
2009-9-21  10:01:22  xu_zh:  这两种方法,我们应该使用哪个方法呢?
2009-9-21  10:03:53  潘:  分析类只是提炼核心域概念,映射到设计以后就变成设计类了。第一种实现起来有什么麻烦吗?
2009-9-21  10:05:51  xu_zh:  那样会有重复代码,而且和业务模型变化比较大,映射后的设计模型和分析模型差别大了不利于认识
2009-9-21  10:06:41  xu_zh:  譬如,两个模块都有相同业务方法,如果写在持久化类中,则这两个模块对应的持久化类都要有这个方法
2009-9-21  10:09:52  潘:  有差别是正常的,有的平台就是要强制要用第二种。Java 还好说,如果映射到C 语言,设计(实现)和分
析差别更大,但其中影射是有规律的
2009-9-21  10:10:02  潘:  两个模块都有相同业务方法--为什么?

2009-9-21  10:11:50  xu_zh:  譬如根据抽样的样地情况计算林班情况,在多个模块都要涉及这个业务方法
2009-9-21  10:12:09  xu_zh:  第一种方法差别大
2009-9-21  10:13:49  潘:  譬如根据抽样的样地情况计算林班情况,在多个模块都要涉及这个业务方法--你画个图我看看
2009-9-21  10:16:13  xu_zh:  第二种只要把分析类和持久类之间建立依赖关系就可以了,分析类都保留
2009-9-21  10:17:23  xu_zh:  分析类直接映射成实现类
2009-9-21  10:23:18  潘:  分析类直接映射成实现类---那也不是分析类保留啊,已经是Java 设计类了。
2009-9-21  10:24:06  潘:  这个不是问题的关键,更常问到的问题是,是否实体类只暴露属性,方法放到另外一个类

2009-9-21  10:26:36  xu_zh:  对我的问题就是这个问题,但是方法类也可以有属性,和业务相关的属性,而不是实体类的所有属性。
2009-9-21  10:27:16  xu_zh:  实体类只有get/set 方法
2009-9-21  10:30:18  潘:  get/set 和"业务方法"都是方法,在平台实现上没有不同啊,不同只是在分析上的不同,××原则,尽量不要调用另一个类的get/set。。。
2009-9-21  10:30:46  潘:  象"温度计",get温度,你说是get/set 还是业务方法