我们经常在设计的时候，会出现设计粒度的问题。我们处理这个问题的时候，会有来自不同方面的意见。认为再细的理由，一般来自扩展性。而来自稍微粗一点的理由，一般都是复杂度。可是我们往往因为不了解业务，而采取更细的设计。
我们经常在设计的时候，会出现设计粒度的问题。这是一个非常难以把握的。很多时候，我们处理这个问题的时候，会有来自不同方面的意见。认为再细的理由，一般来自扩展性。而来自稍微粗一点的理由，一般都是复杂度。
在最近的讨论中，经常听到的是关于扩展性的趋向。可是我们却在慢慢地忘记了一个根本问题：需求分析！
说一个大家可能不爱听的话。大部分系统分析工程师，都是从程序员转过来的。因为大家不是专业的业务专家，所以对业务的把握能力在根本上就不是很好。面对这种情况，很多系统分析工程师在骨子里有一种倾向：用更底层的抽象解决业务的扩展性。
这点虽然不是那么容易说明，但确实是因为不知，所以设计。验证这类设计的方式，就是问他们这样设计的原因，他一开始很可能告诉你是因为扩展。你再问他，是因为甚么扩展。如果他的回答不是很清晰的扩展，那么很可惜，这里的设计，很可能是因为“不知”而造成的。
程序员出生的系统分析工程师，对很多语言的框架有着很深的了解。事实上，这些都是他们成长的必要土壤，对框架他们有很深的情感。当在业务领域不能完全把握的时候，我们往往采取脱离业务的抽象方式，来逃避问题。
比如，我们经常说某个对象的属性可能会变化。那好，我们就来个根本的设计：将对象转换成彻底的类似数据库记录的形式：可以动态改变，可以进行配置。所有属性的访问，都是通过字符型的名称来访问。类似：Fields["Name"].AsString := "新的名称"。
我并不反对数据化的设计，这些灵活性确实有很大的帮助。可是我们在作类似的设计的时候，经常性的问题就是，我们不知道那些对象，到底那些属性是变化的，变化的原因是什么，变化的影响是什么。因为不知道，所以这些问题就不分析了。事实上，这些问题，可能到最后也得不到解决。
我一直倾向于基于分析而设计。对于一个业务对象，我们只有把握住其根本的，才可能正确的把握设计的粒度。对于上面这个例子，我的建议是一个折衷原则：业务对象一些根本的属性，还是一个业务对象，但是这一个业务对象聚合一个可扩展的数据对象。
不管怎么样设计，都是可取的。问题在于设计的背后，我们到底对于业务的把握度有多少。不了解或者不完全了解的情况下，设计出来的系统不能说有什么严重后果。可是对于我们这些热衷设计的人来说，是不可以原谅的。就如面向对象理念在我们心中，都已经成为一个信念！
我曾经接触过一些宣称平台的系统，发现这些平台系统在业务处理上，也是属于“不知”的情况下设计。这类平台，与其说是平台，还不如是框架，或者是架构平台的基础框架。当我们写出真正的平台的时候，我们是必须提供基础的业务实体的，不管是基于对象模型，还是特定的平台业务模型。
总的一句话，爱好设计的我们，不能因为我们的无知，而设计出对未知的软件出来。一个笨办法，好好理解业务！增加我们对业务的把握能力，对系统，对自己都是有非常好的帮助！
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1437856
京公网安备 11010802021500号