这是原创，尊重原创、、、、、、、、、、、、
框架模块设计经验总结三个月没写日志了，比较懒散……下半年准备做OEA 的 B/S 版本，比较复杂，需要从架构设计开始认真入手。正好今天到了部门反思的时间，今天先把原来的一些设计经验总结一下，以方便将来回顾。
直入主题，这篇日志主要用于总结一些框架级别的模块设计经验。
总述
一个大型的框架，必然由多个较独立的子系统/子模块构成。这些子模块如何交互，之间的接口如何定义，这是框架的架构设计的问题。而今天我主要要总结一下，针对其中的某一个子模块，应该如何进行设计。（例如，在 OEA 中有这些相对独立的模块：分布式框架、实体框架、界面生成框架、命令框架、产品线框架、分布式缓存框架、报表模块……）
我在对一个模块进行设计时，大致经过以下流程：预设计阶段、逻辑设计阶段、设计评审、设计调整阶段、设计实现阶段、模块整合阶段。在一次单独的设计中，并不是必须要经过以上每一个阶段。例如，当模块比较简单时，就不需要设计评审、设计调整等阶段了。以下我逐一描述。
预设计阶段
设计开始之前，我们需要为设计做很多工作。其主要的目标是收集并整理模块的需求，力求结构化地描述需求。这些需求主要包括：场景需求、质量属性要求、环境约束。这个过程对于之后的设计过程相当重要，原因也很明显，不再赘述。
场景需求包括：框架用户对模块的功能性需求、70%场景、20%场景、10%场景、API 需求。
质量属性：参考ISO 9126。这里要分析出关键质量属性。
环境约束：技术约束、系统环境等。比较常见的是对原有系统的兼容性。
根据模块的复杂度不同，这个阶段的时间长短可能会有很大区别。例如，界面生成框架在 OEA 框架中是核心模块，在它的 2.0 版本的设计之前，我们平时会不断地收集前一版本的缺点及不足，做整理并使这些杂乱的需求结构化，这个工作“非正式”地做了一年，这些时间都可以算是在预设计阶段中。
最后的交付物自然是：《模块需求规格说明书》。当然，文档这东西，主要用于沟通、传授。可以看情况而定，不一定有这个必要。但是，如果后面有正式的评审会议，这个文档最好还是准备一个正式的。
逻辑设计阶段
关键点：场景驱动设计、质量属性验证设计、环境约束验证设计。前者做加法，后两者做减法。
设计师的经验越丰富，在这个阶段成功的机会也就越大。要满足一套关键质量属性，如果你之前没有遇到过类似问题的话，可能你觉得你的设计能实现，但是最后的事实往往不一定正确。而且设计不象数学那么严格，更象是艺术，艺术靠什么，灵感！所以这个阶段中，不同的设计师很可能会有不同的设计稿。（当然，如果这个模块比较简单的话，很可能设计就不会有什么区别了，毕竟，现有的软件设计的模式是很多的。）
逻辑设计的方法主要还是画图。其中主要还是依据一些通用设计的原则进行设计。
画什么？主要是 UML 中的两类图：静态结构图（包图、类图）；动态结构图（序列图）。
顺带说一句，很多设计人员可能会坐在电脑旁边直接拿 EA 等工具画图。但是我个人比较喜欢的方式是：
- 先用纸笔来画一些手稿。
这个方式主要是比较方便，任何地点都可以画，例如开一些不重要的会议的时候，就可以随手画画。而且最后看着许多有用的手稿，感觉还是很有成就感的，跟画家似的～哈哈。 - 随时想、随时画：
我觉得，一些复杂的设计不是简简单单就能想出来的，特别是我觉得自己的智商只是处于常人智商的范围中，要想出一些卓越的设计，不可能只是坐在办公室的那一点点时间。（我记得我曾在梦中想出了一些醒着的时候想不出来的东西……） - 汇总成正式设计稿。
交付物：UML 图！这是必须的！
这个阶段中，主要考虑质量属性及关键需求。
要提升该阶段的能力，个人再次推荐几本著名的书籍：《Pattern of Enterprise Application Architecture》，《Microsoft Application Architecture Guide》，《Enterprise Solution Patterns Using Microsoft .NET》。
设计评审
召开设计评审会议的原因：
- 人无完人，个人的想法很可能有问题。
- 听取更有经验的人的指点。
- 团队协作、团队沟通。
- 听取模块使用者的建议。
所以，如果不是十万火急，都建议召开评审会议！
我主持过的评审会议，曾经出现了许多的问题，大家可以看看我当时的反思：《反思 - 组内设计评审会议》，不要出现和我一样的错误。
设计调整阶段
没啥，看评审会议的结论。要么做些小的调整，要么大改动，甚至重新设计。如果改动较大，别忘了最后再召开一次评审会议。
设计实现阶段
这个阶段包含了设计的代码验证阶段。
可能由于公司的组织结构不同，这个阶段并不一定由设计师自己去完成。但是我建议不要完全由他人完成，设计就象是自己的孩子一样，辛苦辛苦把他生下来，你让别人来把它抚养大，不觉得奇怪吗？如果你觉得你要设计的东西太多，没时间完成，我觉得你还是少做一些，做好一些会更好。
建议实战能力弱甚至没有实战能力的设计人员不要再做设计了，先好好在底层磨炼磨炼吧。设计师从程序员成长而来，架构师从设计师成长而来，这才是务实的做法！
这个阶段考验的是设计人员的代码实现能力，团队协作能力。代码的实现能力往往真正能看出一个人的设计能力。软件设计原则大家都会说，但是，要真正把这些原则应用到代码实现中，却需要时间的不断磨炼。如果开发组里能有几个为技术痴迷的人，那是最好不过的了。
实现相对于设计稿，可以有一些更多的灵活性，并不一定要100%符合设计稿，这是因为代码实现本身就是一种微观的设计。但是必须要求80%以上是要符合设计稿的。如果实现过程中，不得已有过多的部分不符合当初的设计稿。请：召开讨论会议！重新画图描述当前设计！总结反思！
值得一说的是，实现阶段需要着重对使用场景进行 721 分析，设计良好的 API 以应对这些场景，并配以相应的单元检测。关于框架设计中的场景驱动设计，大家可以看这篇文章推荐的书籍：《Framework Design Guidelines 2nd Edition》。
模块整合阶段
其实这个阶段中的工作在上一阶段中需要准备好，也就是说，在进行编码时，需要不断考虑所设计的代码能否在大的环境中运行。所设计的接口是否能和当前系统正确的衔接上。如果之前的代码没有考虑足够，在这一整合阶段中，可能会发生一些集成的问题。不过这种情况我遇到的比较少，这里就不展开了。
这阶段完成后，最好能配上集成测试。（不过我目前都没有做过。）
演进模块的考虑点
在整个框架的架构设计完成之后，其中所涉及到的模块分两类：一类是在架构设计时已经考虑到并明确定义的模块；另一类是架构初始设计时并没有考虑到，但是随着系统逐渐演进，发现必须被添加进来的模块，我简称其为“演进模块”。两种模块的设计有许多相同之处，相对而言，设计演进模块时，相对要需要考虑更多的东西。
针对演进模块，在预设计阶段，约束中需要重点写明历史系统对当前模块的兼容性约束。在设计阶段，需要分析当前系统，从中找到突破口。
兼容性是很麻烦的一种约束，为了满足这种约束，常常会使简单的设计变得复杂。最后的代码也很可能写得不符合规范。在以后的新版本中，如果做出不再兼容这些历史代码的决定时，这些兼容性设计需要被删除。
设计失败的常见原因
- 预设计阶段工作做得不充足。
未收集场景、早早地进入了逻辑设计阶段、甚至直接开始编码，导致最终设计了不需要的部分，或者根本满足不了需求。 - 过份自信，未召开评审会议。
- 设计经验不足。（逻辑设计要求经验、灵感）
提升方案：多把现有系统画出来。架构模式、设计模式都熟了吗？平时有没有花非工作的时间多设计些东西？书看太少了？ - 编码能力不强。（代码实现要求实战家。）
提升方案：天天写些无聊的代码？非工作时间有多少花在代码上？书看太多了？ - 逻辑设计、代码实现分两波人做。
总结
这篇文章是基于目前我的设计经验总结而成，将来可能会不断更新……
同时，希望和园友们交流设计经验。更加希望平台开发人员能和我一起交流平台级别的开发。
可以短信我，交换QQ和EMail。