the5fire

  在软件设计中粒度的把握就像是人际交往中热情的控制，你对人太热情了吧，别人可能觉得你有什么企图；对人太不热情了吧，别人又会觉得你这人冷血动物。这个绝对是一门学问。


  既然是一门学问那就不是吾辈刹那间可以搞清楚和明白的，因此写这篇文章也是发表自己的看法，和大家共同探讨。

  关于需求：
  需求这方面可以说是越细致越好，我觉得有两个词来描述需求设计：精细，准确。这二者缺一不可。


  对于一个项目来讲需求的设计可以是决定了以后项目的修改，重构甚至是能不能交付。因此在前期需求处，越是将客户的需求描述的清清楚楚明明白白，后期的开发工作越是心里有底。


  如果需求描述的过于精细可能会觉得太过于繁琐，这时就需要考虑“准确”了，就像是射击一样，如果每一个精细需求的末端都能命中靶心（客户的心意），那就不会有繁琐的感觉，相反这时会觉得这个设计做的很舒畅。（这种感觉只可意会）


  不过需求的细化是需要时间的，为了保证项目开发周期，起初的需求分析不可能让你有足够多的时间。

  就像是我们在做餐饮系统时一样，客户要求两周就要出，因为赶时间做培训。在没有足够的时间做需求的时候最佳的办法就是找模型，或者根据客户的描述快速建立起一个模型来。不过这种短周期开发的弊端是后期维护很困难，或者说是麻烦更好一些。

  因为起初并没有客户完整的需求，后期客户在要求增加需求的时候你必须基于已经开发出的东西来做，因为项目已经在运行了，可能推翻重来吗？这时的感觉就像是带上枷锁跳舞。

关于设计：

  1. Dao层的粒度：

  上一篇文章《软件设计：DAO层该如何设计》中没有谈到粒度的设计，只是说了类结构上的设计。那么Dao层的粒度该如何设计呢？

  个人感觉这里的粒度就是每一个Dao类中的方法的个数，其对数据库内容的可操控程度。

  Dao层的设计是不涉及到业务的，但是它必须能够满足业务。就像是在上篇文章末师哥所说“dao层的操作是对业务的一个分解，把一个完整的业务分解到数据库中的相关表中”，那么既然是分解，其粒度自然就不粗了。不但不粗其粒度应该更为细致才好些。因为Dao层的设计应该是越简单越好，即便于调用，也便于维护。

  2. 业务层的粒度：

  这一块不太好说，一般业务层都是按照软件功能来划分，不过粒度不应该太细，毕竟是要被表现层调用的，还是不要让表现层知道的太多为妙，免得“死于”-你知道的太多了



  以上只是个人的一点看法，欢迎各位斧正。 - from the5fire.com