要整一个类似邮箱的短信发送应用，要求：
收信箱：查看上行短信
发信箱：查看已下发短信
垃圾箱：查看已删除短信
草稿箱：查看保存的草稿
现在我的想法是：
信箱[收信箱、发信箱、垃圾箱、草稿箱]
短信
具体实现时，将短信中加一个标志位，加以区分此短信属于[收信箱、发信箱、垃圾箱还是草稿箱]，但是现在有一个问题是，当发信时，即可以将此短信归属到草稿箱中，同时还可以归属到发信箱中；针对这种情况，我想将短信的标志位设置为一个整型，将归属[发信箱、草稿箱]的短信标志位设置为大于或小于指定数值的整形，不知道这样是否可行
如果用OO的思想如何来整理？
[该贴被wyz191于2012-11-07 08:25修改过]
业务用oo基本采取ddd,信息和信箱是两个主要实体，信箱可以看成是信息的距合体，作为根实体，下份几个继承子类：收信箱，发信箱等。
我认为不应该为了OO而OO,
应该深入分析需求，找到事物之间的客观联系。
以你的这个问题为例子，一封信件可以同时存在多个信箱，我的理解对吗？
如果是这样的话， 对每个信箱编号1,2,4,8,16, 信件的标志位直接使用信箱编号的或操作就行。比如 1|2代表同时存在于1信箱和2信箱。
以上
[该贴被alexwoo于2012-11-07 16:17修改过]
现在有三种用户：
1、部门用户[收发维护本部门短信]
2、个人用户[收发维护私人短信]
3、部门领导[兼有1、2用户的功能]
针对上面提到的信箱，有一点尚不确定，信箱是用户获取短信的窗口，那么针对信箱是应该让用户去取短信呢[信箱不与用户关联，将信箱当做一个仓库，给信箱单号，信息给你拿货]？还是让信箱给用户短信[直接标明信息是某个用户的信箱]？
不妥，信箱是信息的聚合体，信箱可直接和所有者用户关联，信息可通过所在信箱导航得到关联信箱的所有者用户。
针对短信的情况：
短信分为：
1、上行短信
2、下行短信
a、立即发送短信
b、定时发送短信
------------------
a1、点对点发送：发给一指定号码，号码主人未在系统中注册
b1、群发：所有接收方均在系统中注册
针对这种情况，用OO应该设置一个根类SMSInfo,然后再细分为：
根：SMSInfo
子一：UpSMSInfo DownSMSInfo
子二： DownImmeSMSInfo DownNotImmeSMSInfo
是否应该细分到子二，还是分到子一然后在下行中设置一下行时间？
在收取短信时，所有的短信如果都同下行短信号码来匹配，a1、b1的情况应该可以忽略，这块是不是可以忽略过去，不做过多考虑？
针对信箱：
在根［信箱］下细分为[收信箱、发信箱、草稿箱、垃圾箱]
根：SMSBOX[数据：短信 行为一：存信 行为二：取信]
子一：SMSDraftBox SMSDustBox SMSReceiveBox SMSSendBox
然后，在实际操作中，在外面包裹上一层信息过滤，这样是否可行？
[该贴被wyz191于2012-11-08 10:06修改过]
以上这些属于用户对短信的操作行为，以购物车为案例，用户增加 修改购物车中的商品，都属于用户操作行为。
“用户操作短信的行为”可以解释为：用户 + 发出操作指令命令 + 短信的相应行为被激活。
分析首先从名词和动词两个方面入手，也就是区分静态结构和动态行为两个方面入手：
至于上行短信和下行短信可能不属于动态行为，而是属于和动态行为有关的状态，如果这个短信被上行行为操作了，那属于上行短信，本质还是属于短信，只是短信在特定场景实施了动态行为，可以将上行短信看成是短信扮演的上行角色。
静态结构和动态行为两天线路可以很清晰落地，常见下图：
图中，领域--聚合--实体 属于静态结构；场景 事件和状态属于动态行为，当然状态特殊一点，属于静态和动态结合点，这点经常被混淆，要么和实体固有属性混淆，要么和事件行为混淆，比如上行短信和下行短信。
建议楼主多了解一下DDD，聚合根是需要的，比如SMSInfo。
邮箱、短信讨论了半天，实质就是邮箱、短信的一个分配问题！
信箱、短信与用户最好分开设计，不需要进行任何偶合，他们分属不同的场景，否则信箱使用范围就会被“用户”限定死了，针对信箱的多用户使用与一个用户同时使用多个信箱的问题，本质上是用户的一个信箱地址的分配问题。
当然还要解决一个来信短信提醒的问题，可以在邮箱接受信件事出发一个来信事件，过程可以这样设计：
Hr模块场景订阅来信事件。
邮箱接受信件事->邮箱上下文处理事件(比如：完善时间内容、技术上ServiceBus进行发送等)->事件订阅场景处理来电事件，产生短信发送事件（hr根据邮箱地址找到该地址的所有使用者，获取电话号码发送短信提醒）->短信处理场景处理短信发送事件
如果hr行政部门对邮件有写特殊的控制，邮件字串地址做成一个MailAddress对象，加上MailAddress的邮件控制属性、短信控制属性等
这个发短信问题看是一个短信问题实质也个业务控制问题，主要是考虑相关的控制属性应该放在哪些类上
对短信发送事件做一个EventScheduler来执行。对短信模块而言只要收、发，
既于是部门收发还是个人收发放到业务模块，否则信箱、短信就太死了，过程与油箱来信一样，可以写一个短信到达的事件一样处理。
如果进一步抽象的话，MailAddress、MessageAddress继承一个共同的Address基类，拓展性就话好一点了，
DDD设计不怕聚合根或对象方法没找到或找错了，最担心的没有看到潜在的对象把一些系统不相关（可能业务相关）的对象硬塞到系统，这样太容易迷失方向。（个人观点，DCI设计最大毛病就在于此，因为它太接近业务描述了）
不好意思，文字描述没什么条理，想到哪写到哪，将就着看吧 .....
[该贴被clonalman于2012-11-10 04:48修改过]