邮箱、短信讨论了半天,实质就是邮箱、短信的一个分配问题!
2012-11-08 08:53 "@
banq"的内容
不妥,信箱是信息的聚合体,信箱可直接和所有者用户关联,信息可通过所在信箱导航得到关联信箱的所有者用户。 ...
信箱、短信与用户最好分开设计,不需要进行任何偶合,他们分属不同的场景,否则信箱使用范围就会被“用户”限定死了,针对信箱的多用户使用与一个用户同时使用多个信箱的问题,本质上是用户的一个信箱地址的分配问题。
当然还要解决一个来信短信提醒的问题,可以在邮箱接受信件事出发一个来信事件,过程可以这样设计:
Hr模块场景订阅来信事件。
邮箱接受信件事->邮箱上下文处理事件(比如:完善时间内容、技术上ServiceBus进行发送等)->事件订阅场景处理来电事件,产生短信发送事件(hr根据邮箱地址找到该地址的所有使用者,获取电话号码发送短信提醒)->短信处理场景处理短信发送事件
如果hr行政部门对邮件有写特殊的控制,邮件字串地址做成一个MailAddress对象,加上MailAddress的邮件控制属性、短信控制属性等
2012-11-08 09:53 "@wyz191"的内容
针对短信的情况:短信分为:1、上行短信2、下行短信 a、立即发送短信 b、定时发送短信 ...
这个发短信问题看是一个短信问题实质也个业务控制问题,主要是考虑相关的控制属性应该放在哪些类上
对短信发送事件做一个EventScheduler来执行。对短信模块而言只要收、发,
既于是部门收发还是个人收发放到业务模块,否则信箱、短信就太死了,过程与油箱来信一样,可以写一个短信到达的事件一样处理。
如果进一步抽象的话,MailAddress、MessageAddress继承一个共同的Address基类,拓展性就话好一点了,
DDD设计不怕聚合根或对象方法没找到或找错了,最担心的没有看到潜在的对象把一些系统不相关(可能业务相关)的对象硬塞到系统,这样太容易迷失方向。(个人观点,DCI设计最大毛病就在于此,因为它太接近业务描述了)
不好意思,文字描述没什么条理,想到哪写到哪,将就着看吧 .....
[该贴被clonalman于2012-11-10 04:48修改过]