banq说的确实深有体会.数据表先入为主概念容易让领域建模误入歧途.面向数据库表的思维对现实世界进行抽象化和概念化比较困难.具体表现在我们的程序缺乏和现实世界领域的对应关系,对现实建模无能为力(或者是数据库建模对现实世界的模拟和映射并不自然和精确,因为数据建模无法映射现实业务实体抽象和具体,部分和整体的的关系,也无法映射业务实体与生俱来提供的行为和职责),建模就是将现实中的事务和计算机中的事务相互匹配和对应以及模拟,同时现实世界上是同时对数据以及对数据的操作是一个整体,而数据建模则没有.在实践中,我感觉到数据建模处理大型的异常复杂的业务是有些力不从心,前端表现层和后端耦合过紧,牵一发而动全身.数据建模解决了数学上的关系完整性的问题,却没有解决业务概念的完整性的问题(即不能完全模拟业务概念).
感觉到,jdon上面讲领域建模概念的和好处以及例子(如jivejdon)的很多.但是具体暴露建模的细节的这一思维过程的文章很少,也就是是说,如何去建模的文章太少(比如说如何去发现领域对象,如何发现领域对象的职责),希望banq以后多讲点儿建模过程的文章..呵呵
我个人觉得领域建模至少有以下几个步骤:
1.发现领域对象 方法有:领域的常识,前一个类似的系统抽取业务词汇 ,企业模型或供参照的体系结构 ,词汇表,报表,表单.一般可以通过名词语法分析来发现领域对象:这些名词一些是类,一些会成为类的属性,一些对我们的系统无关紧要 .每个名词或者形容词+名词的组合,我们把他们找出来,看哪些是我们候选的领域对象.一个常用的方法就是:用一些简单的问题来测试每个词.这个名词是否在系统的边界之内?这个名词可以拥有或者提供某些系统的服务或功能吗?这个名词拥有或者管理某些数据吗?这个名词和其它名词之间有什么关系吗?如果所有答案是"是",这个名词可能就是我们要找的领域对象.
2.弄清领域对象之间的关系 重点放在分析业务领域概念及其关系上,弄清领域对象的关系是:一般和特殊(继承),部分和整体(聚合和组合),还是关联和依赖等等
3.弄清领域对象的职责 CRC (类/职责/合作关系)方法 即通过基于角色的设计,通过角色的抽象和协作来弄清类的职责.即每个对象是一个角色,它对外提供什么服务,有什么职责,它维护和管理哪些信息,它和其他对象协作完成什么服务.CRC技术通过角色扮演的这种拟人的手法,以对话的形式模拟现实世界业务领域概念的行为,各种角色扮演不同的功能协作满足要实现的功能,是比较好的发现类的职责的方法.
4.弄清领域对象状态的变迁 使用UML状态图表示,如银行账户对象有正常,挂失,冻结,销户等状态.
5.领域对象相互协作提供服务 通过已有领域对象的组合和协作完成新的功能,领域对象的可重用性在此体现.
6.通过设计模式精化重构领域模型满足具体软件技术架构层次上的要求.
整个建模的思维过程就是一个探索复杂问题的过程,一个从模糊到清晰,从零散到系统的,从点到面的过程,从混沌到条理的逐步演进的过程.
[该贴被kylix_xp于2009-03-13 00:27修改过]
[该贴被kylix_xp于2009-03-13 00:28修改过]