请教一个领域设计的问题

您好，各位高手，小弟最近在设计一个关于水情监测信息的系统，这次使用了Hibernate作为持久层的框架，因没有领域设计的经验，故来请教各位，以下是我个人简述的情况和一些想法。
本系统主要用于发布和管理水信息以及操作预案，其中该系统分两部分，第一部分是通过在河边各监测站的测点采集数据，并统一的放入一数据库中（这部分不需要我负责），我的这块就是从这个数据库中读取数据放入另一个数据库中，进行处理和发布。
系统主要有几大块：
首先用户身份分为注册用户和管理员两级
监测站根据类型可以分为水质监测站、水位监测站、泵站、闸站等。。
用户可以查看的信息分为两块实时信息和历史统计信息
此外可以查看的信息还有河段和断面
管理员可以选择和执行各种水情调度的预案（这个由专门的专业人士给出算法，本人将其作为业务逻辑已经实现）。
因没有领域设计的经验，有些不成熟的设计和想法，希望各位给予批评和指正
首先我将域对象分为：
User（用户）
测站 (具体的水质监测站、水位监测站、泵站、闸站等通过继承该站实现)
实时信息（具体化后分为实时水情、实时水位等也都通过继承）
历史信息（历史平均水位、历史水情等同样使用继承）
RIVER_INFO河段（测站和河段是一对多，一个测站可以测多个河段）
DM断面（断面和河段是一对多）
Program预案（管理员一次可以使用1种预案，这是一对一的关系）

请问下怎么设计成领域模型，把握不好粗细的粒度。。谢谢。

你这个系统主要是记录，没有对行为过程的跟踪tracing，所以相对比较简单，只要找出高聚合的静止关系就可以了。

找出核心模型，就是这个系统监测信息的主要主体。从你提供有限需求信息中还是不能了解：实时信息是否是发生某个测站中某个河段中某个断面的水情或水位信息？

如果是，那显然，不同断面的水情信息就是两个不同的Object，就象在轿车上的玻璃和在房子上的玻璃分属不同的主体，玻璃和轿车是聚合关系。那么断面和水情也是紧密的聚合关系。

至于测站和河段以及断面是一种Compsite组合关系，可以采取类似展会展区展位或论坛主题贴帖子这样分级树形结构来解决，测站和河段以及断面合并在一起决定水情的发生的地方或位置。

首先谢谢彭老师，遵循DDD,应具体根据什么步骤？我的领域模型应设计成什么样子
应提取什么信息，抛弃什么？
我现在的想法是
首先抽象出来的实体类
User（用户）Station（测站）Rinfo（实时信息） Dinfo（历史信息）
RIVER_INFO（河段）DM（断面）Program（预案）

关系：除了继承关联聚类还有什么？都要显示在类图上吗？？图会不会很复杂
1. 继承关系
Admin（管理员）和Register（注册用户）继承User（用户）
Sstation（闸站）、Pstation（泵站）、Qstation（水质站）、Lstation（水位站）继承Station（测站）
RS （实时闸位）、RS （实时闸位、RP（实时泵位）、RQ（实时水质）继承Rinfo（实时信息）
DP（历史的泵位信息）、DS（历史的闸位信息）、DQ（历史的水质信息）、DL（历史统计的水位）继承Dinfo（历史信息）
2 关联关系
Lstation（水位站）用于测RL（实时水位）和统计 DL（历史统计的水位）这里应该是一对多 1：N
Sstation（闸站）用于测RS （实时闸位） DS（历史的闸位信息）1：N
Pstation（泵站）用于测RP（实时泵位） DP（历史的泵位信息） 1：N
Qstation（水质站）用于测RQ（实时水质） DQ（历史的水质信息）1：N
Station（监测站）和StationAlarm（站报警）是1对1（这里是关联还是聚类）
StationAlarm（站报警）用于测DeviceAlarmConf（设备警报配置）
Staion（监测站）和Device（设备）是1对多 Device和Devicestatus（设备状态）状态是1对1
Staion（监测站）和RIVER_INFO河段（测站和河段是一对多，一个测站可以测多个河段）
RIVER_INFO（河段）和DM（断面）是1：N
Admin（管理员）和Program（预案）是1：1，管理员一次可以使用1种预案。
3 聚类？目前没看出来

[该贴被wlcome998于2008-01-01 22:00修改过]

这几天抽空对模型梳理下，理清了很多关系，以下我简单的列出了一个实体间的关系图，请教下各位，根据改图怎么样表达出域模型的设计图，还需要哪些改动和变化，谢谢了。。
主要关系为：
1Admin（管理员）和Register（注册用户）继承User（用户）
2用户可以查看各种信息，信息分为实时水信息和历史统计水信息，信息主要有水质、水位、水流、雨量信息组成。
3 河道分有几段河段组成，一段河段上可能存在几个断面
4 水闸和泵站都存在于某一河段上。
5 水位测站用于监测实时信息和历史统计信息。

[该贴被wlcome998于2008-01-14 16:55修改过]

我比较习惯用四色原型和DDD分析，不习惯ER模型。我也建议你用四色图来表达你的需求和简单分析。

世界是事实的总体，而不是事物（对象）的总体，在事实中对象以一定的方式相互关联，所以我们分析一个系统时一定要了解这个系统主要是描述什么事实，根据这样的事实提取什么样的信息以做出特定的决策。

在软件的分析设计中用四色原型来表达系统非常合适，其中的核心MI正是用来描述这样的事实的，其他一切都是用来描述组成这个事实的对象以及对象本身的一些信息的。

楼主这个系统是一个关于水情监测信息的系统，它主要描述的事实即水情监测信息可以用一句话表达，那就是：“某人记录某一时刻某一监测站的水情数据”。这个系统其实并不关心各测站如水质监测站、水位监测站、泵站、闸站的具体信息，所以不建议把他们作为测站的具体子类来处理，而是把他们做为测站的类型。同样，管理员和注册用户也不适合继承用户，而是作为用户的角色。历史信息和实时信息也不适宜分开，因为实时信息也是即将变为历史信息的。对于什么河段断面等是次要信息，不做讨论。

[该贴被killer于2008-01-19 22:47修改过]

谢谢楼上的，受益匪浅，呵呵，能否给一个简单的域模型图设计图来示例下，我本意是想根据实体之间的关系画出域模型图，而不是做需求，域模型中实体间关系通常是由关联(association)、依赖(dependency)、聚集(aggregation)
一般化(generalization)组成的

类之间的继承是需要特别小心的，有些概念你确实可以说是继承关系，比如人事考勤里面的员工分为男员工和女员工，你可以说他们都是继承“人”这个类，但是在你的系统里并不会具体去关心男人和女人的细节，仅仅作为一个性别标识而已，所以在类的表达里，把性别作为员工类的一个属性。你的这个例子中的各种监测站和测站的概念就和员工的概念类似，所以不建议把它独立出具体的子类，只需要作为类型属性即可。