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 还是业务方法
|