我没有把具体需求说清楚，所以不存在答案，killer的分析给了我很大的帮助，经killer这么一说好象一些本来模糊的东西变得清晰了。
整个需求是通过这个网站，让去看展会的人能更好地了解到展商的信息，参加展会的人虽然最终目的是产品，但通过这个网站系统更多是想了解他感兴趣的产品的展商，而不是产品本身，当找到展商后，可能才会去找这个展商的产品或者是展商在某个展会的某个展区展示的产品。（可以去展示某类产品的展区找展商，很少是找展商下的产品然后找到展商），这是我对展会网站的理解，因为我觉得展会网站是不会替代展会本身的，展会网站只是对展会提供服务。
图2其实是我的设计图，可能不能表达我的思路，我不会画图，只是说明实例与实例之间的一对多或多对多等 关系，我只是简单的以为在实际操作中能从展会能找到展区和展期，所以展会与展区之间，展会与展期之间有关联。
其实一看，图2虽然是类图，却又是数据库设计的结果，正是killer 所说的“这里并不是简单地把现实世界的实体一对一的映射为类，如果是这样的话仍然只不过是面向数据库的简单的变种”，还是没走出数据库的影。
killer的图看得不清楚，是不是每个实例都是与展会关联？除此外其它实例间没有直接关联？
那么在操作中是怎样从展区找到展商，如果能找到，那不是展区和展商就有关联吗？在数据库上说就是展商中有个字段是放展区的主键。可能killer说的才是真正的领域图，请指点。
对killer的分析有以下几方面理解不透
1“展期—展区—产品类别—公司”怎么的理解呢，是说展区与公司没有直接的关联，是通过产品类别来找到
2.“我们假设一个展区在不同的展会甚至同一展会的不同展期内可能展示不同类别的产品”，我之前是想过在展区定义里要独立出展区实例这个概念，就好象展会与展会实例的关系，但又觉得这样复杂了(实现复杂，用户操作也复杂，要去建展区定义，而这个展区定义可能会很多)，考虑到很少会说要找通过展区定义找所有这类展区实例，所以就把展区定义去掉了，其实这样也让展区实例之间失去了关联。为什么在区分展区实例呢，比如2007年上半年广交会的工业展区和2008年上半年广交会的工业展区不是同一个对象实例，它们有各自的展商，各自的展区图片，各自的介绍等等。如果是这样设计，那应该是不会存在“一个展区在不同的展会”在不同展会看作是不同展区了，展区与展会是一对多了。不是多对多。
3."所以为了保证系统的扩展性，类与类之间的关联不能太多，没有本质关联的对象之间绝对不能加上不必要的关联",怎样才算是有关联呢？在类与类之间的关联对应到数据库就是外键是吗？“类与类之间的关联不能太多”是说冗余关联吗？因为有些关联是必然的吧。如展会与展期的关联，展区与公司的关联。而展会与公司的关联和展会与展区的关联就是冗余关联。
4.“展馆展区其实也就是一个展区的概念，类似产品类别的概念。”要看业务要求了，如果对展馆展区要求不高时可以合成一个展区的概念，这样关联就简单多了，但如果从客观世界来说“展馆展区”本来不是同一类的东西，放在一起会不会违背某种思想？如果系统做大了，展馆展区是要独立出来的了，因为它们属性根本是不一样的。这个疑惑和“要不要增加冗余关系”一样，增加冗余关系会使对象关联变成蜘蛛网，但可能更符合某些业务要求(性能),当然这些冗余关系不是随便加的，是考虑到"展会实例，展期，展馆，展区，公司之间的关系基本上是最少改变"。象“合成一个展区”，“冗余关系”这类感觉违背某个思想的要怎么取舍呢。
OO思想都是从现实生活转换到软件世界的一个过程，正如killer所说的是一个抽象的过程，一个是怎么“抽”，抽出来怎么去判断“象”，而这个过程每个人的理解都不一样，到底去怎么定义？
现实生活与软件世界，个人认为是怎么抽象都是不会相等的。只有在这中间找到一个“度”，在领域设计过程可能偏向于现实，在代码与数据库实现则偏向与软件世界，到底怎么去掌握这个“度”？
5.产品类别是直接与展区关联，算是展区的一个属性,表明这个展区显示的类别(只是分类，不表示这个类别的展区一定不可以展示其它类别的产品，也就是展区中的产品类别与公司产品中的产品类别是两个不同的，没有关联的东西)。产品类别还与公司的产品有关联。
有个不清楚的问题，领域分析，oo思想，能不能解决以下问题，如果能，体验在哪方面：
1.系统前段要求不高，只是展示简单的展会信息，展会有什么展区，有什么公司参展。这时候分析出来的核心对象只是展会，公司等 。但系统后期，做大了，可能要求展期，展馆等都是系统中一个重要的模块，在展馆模块的展示页面，可以了解到某个展馆各方面信息，如在这个展馆中展出过的展会，展馆的图片，展馆的所在城市，展馆里的场馆，楼层，占用面积等。这时候，展馆就从之前的一个不核心的对象变成了一个核心的对象了。用了领域分析,oo思想后，这些的需求变化系统是怎样轻松应对？当然不可能在系统前段就做到系统后段的功能，成本的问题，而且系统也不一定做大。
看了killer的东西还有一种体会是能把一些东西用固定的思维模式来思维并表达。
现在我分析东西连自己也不敢肯定是对的或是全面的，正是想找这样的方法论。
看了展会实例职责分析后，对怎样区分对象的职责有了实质的头绪。从分析层面看，区分好职责能更能反映客观事物，从具体的实现层面来看，区分职责在是不是为了更好地放置代码吗？
但是要通过展区得到有哪些公司则必须给广交会实例分配按展区查找公司的职责，表达如：广交会实例.get公司by展区(展区：展区实例),如果从具体的实现来看，这句话可不可以理解为：如果我用贫血pojo，就是应该把 “get公司by展区(展区：展区实例)”放在展会实例的服务层，而不是放在公司或展区的服务层。从代码的放置来看，这样对吗？
再次多谢killer 和banq的回复，让我学到了很多东西。
