在工作中遇到的一个设计问题

关于一个设计的问题.
最近在做一个系统,与邮箱系统有点类似,但又不全是,大概需求是:

一个用户提出一份报告,然后将这份报告发给他的上级<不同位置的用户上级不同>查看处理,不管上级怎么处理,都必须有个回复,同时只要涉足过这份报告的用户都可以查看这份报告的情况,这份报告在不同的时间内会有不同的状态,
大概就是这样

根据这些需求,我们首先提出以下结构:
报告,BOX<在编,草稿,发件,收件,待处理(事情没完),已处理(完了)>

class Report{
	//用来标志这个报告在那个BOX内
	int box;
}

/*******
* service,从某种意义上来说,算是一个转发的功能,但不全是,因为它们还有一个更重要的职责,封装步骤
******/

//发送管理
class senderService{
	//包括新增,发送	等,发送及发送前对报告的操作,如:

	//这样写有点奇怪,但是将USER当成一个所有者就好理解了,即,这个报告是他的
	public void send(Report report, User user){
		inbox.putin(report, user);
	}
}

//处理管理
class operatorService{
	//包括发送后对报告的所有操作
}

/**************************
* 以下都为Manager非service,由于上面对具体步骤进行了管理,这里对每个BOX的操作就很单一了,且相差不大
*************************/

interface Box{
	public List<Report> list();
}
//
interface Sender{
	//放入,report报告,owner所有者(我觉得这个概念很重要)即目的地
	public void putin(Report report, User owner);
}

interface Operator{
	//回复
	public void putin(Report report, String writeBack)
}

//在编,处理没有发送前的报告
class Editbox implements Box,Sender{
}
//收件,处理收的
class Inbox implements Box,Sender{}

//待处理,所有处理后不能在现实实现的报告
class Staybox implements Box, Operator{}

//完成
class Endbox implements Box, Operator{}

//DAO,所有BOX对报告的修改都调用这个
class ReportDao{}

在每个BOX中我刚说了一个很重要的概念,所有者,即当前放入BOX的报告是那个的,
这样的话对所有BOX我只要对它说,我是那个,你把我的东西保存起来或把我的东西拿出来.
而在BOX内是直接修改Report的BOX属性,以给定它的所属.(我在这里没有将BOX属性,当成状态!!!而是看成它属于那个BOX)
以及其它信息的处理(现在不多),然后调用DAO持久化

以上是我的主要思想,其实,以前,我是把Sender,Operator接口继承BOX的,同事坚决反对后去了...


然后,我的同事却不想这样做,主要原因是,他觉得BOX太多了.而且每个BOX内的东西相对都很少,最重要的一点是每个BOX内都是改Request.box属性,他想直接在senderService,operatorService里面改这个属性...这样至少要少5个类,5个接口(Spring的原因).所以他觉得我那样做太臃肿了


我之所以搞出那样的处理方式,是想真正的将系统当成对象(希望能做成一个领域模型)一样的去处理,而不是为了实现功能而实现.

首先,希望大家能对我这样的处理方式进行批判,其次,也帮忙分析一下我与同事的分歧
在此先谢谢各位了

个人观点:

至少先提取出报告的生命周期吧,然后把生命周期这里设计一下.

生命周期这里就包括了本身的状态,以及状态之间的迁移应该触发本身的信息变化(这里可以做的稍微可配置一下,也不用限于本身的信息,比如对外的触发也可以,类似发消息)

重点还是生命周期的设计,所以Stay,End这些就不需要实现了Box和Send接口了,而Send应该设计在状态迁移过程的一个操作.

我说说我的想法:
我觉得不应该有BOX的存在, REPORT是一个实体, 把Services抽象出来,派生你说的senderService 和 operatorService等操作, 至于用户我也会抽象出来,现在目前来看可以派生2个 一个sender角色, 一个Operator角色

另:
楼主,你这些 <在编,草稿,发件,收件,待处理(事情没完),已处理(完了)>  状态都是需要持久化的吗?

在界面上会有某种操作的业务接口,
在service中封装这些业务的步骤,

关于报告的生命周期:
发送->处理->等待->完结
          |_______|

由于有这样的业务所以Stay,End是必须的,虽然不一定是BOX的形式
关于状态的迁移,都是在BOX中进行,

这里可以将BOX想成一个银行.
外面的人不用知道银行把我们的钱放在那里了,怎么了
只要我们把我们的一个标志(卡)及钱拿给前台MM,他就把钱存到我的名下,
而要去取的时候也是把我的标志给她,她就把属于我的钱给我,....

你用个工作流不就完了吗？

我们也想用工作流呀...
可是这个东西不全是工作流...
根本就不能用那东西...
  

我们同事最近做了个工单系统，由用户填写工单，然后发布，然后工单就有类似你上述的几个状态，到最后处理完。中间加自己的业务逻辑。
用OSWorkflow做的工作流引擎，自己扩展的工作流适配器，完全可以满足你的要求呀，工作流就维护你那报告的状态，有啥不能用的呀？

我看也就是工作流

你看一下设计模式 就清楚了

能不能说具体点?