架构思路

。。需要一些思考　当前的架构是
BO+DAO+BS+TS+BB+VO
BO只是简单的pojo
DAO是对一张数据库表的CRUD
BS是简单的业务元子
TS是业务逻辑组合层
BB是前台的控制层
VO是前台数据显示层 负责将BO的数据显示到前台　进行一些Id和Name之间的转换
再想说这些各层次之间数据的交换是否应该严格限定死
如DAO和BS之间只是简单的BO作为数据传送实体
BS 和TS 之间也是BO作为数据传送实体
TS和BB 这一层可能的数据传送实体可能最麻烦了。。　比较好没办法严格限定死哪种数据实体。　设想BO 和VO　都可以作为数据传送实体？？不知道是否有违背了某些层数据交换的思想呢。。？？　还有VO 这一层也存在某些争议。　普通的pojo可能会在多个BB需要用了。　难道需要转换的时候都在各自需要的BB进行转换吗？？　有点不解。。 还有一点Id和Name 对应的Map 以及List放在各自的BS里面。。　然后有谁需要用到的时候就去调用相应的BS　　。再着考虑是否可以将　这些ID和Name对应的Map都统一到一个数据实体中去呢？？　　
总之：多层思想是不错的。。但发现这里面最大的一个难点就是如何严格控制各层的功能以及各层之间的数据传送实体。以达到尽可能的灵活性及复用性。健壮性等等。。　要不然你会发现写出来的代码将会是相当悲惨的。。　这或许就是考验一个架构师的水准吧。。
忽然觉得工作流的思想挺不错的。。是否可以将其用在指导架构方面呢？　应该是个出路。。　　多层架构一单层架构之间的差别有点类似于　树结构和有向图的区别。。　树结构看起来相对会比较清晰。
而有向图说明白点就是有点像一个蜘蛛网。。　天知道哪天会出现什么大问题。。。。　或许是对树的偏爱才会这样说吧。。。但发现有向图般架构的程序到后面维护的时候肯定会被人给骂死的。。　我就不相信树结构会比蜘蛛网难以理解。。。　人的精力是有限的。。　不可能从一个网中找出问题的所在。。　但树就比较容易确定问题的所在了。。　如一棵树某一结点功能出现问题。。首选检查它的本身有没有问题。。如果没问题。。则检查它的子结点。。　是否出现问题　这样一层一层检查下去。很容易就能够确定问题的所在了。。
但如果有有向图可就没那么好找了吧。。天知道是哪个环出现了问题。。　只能顺着有向线段　查找一下。。　如果此点有N个有向线段那就意味有N棵树需要去查找才能够确定问题的所以。。　一棵树　对比N棵树　想想就知道后期维护的不同难度了。。　人的思维永远是比较容易理解树结构的。。而不是图结构。。
或许树结构就是有点根据工作流的思想来指导架构吧。。希望能够有高手来指点一下　
PS：写得有点乱。。这是我对架构的一些想法。。　欢迎提出意见。。