怎样的架构才算好？

软件开发过程中所得到的经验分为两类：关于过程的建议和关于产品（或结构）的建议。
关于过程的建议有：
 1>架构的设计应该由一位设计师来完成，或者由某一个在某位设计师领导下的小组来完成。
 2>设计师应该全面掌握系统的功能需求，并且应有一份所设计构架应满足的划分了优先级的质量属性列表（如安全性或可修改性）。
 3>架构文档应该完备，至少有一个静态视图和动态视图，应该采用所有人员认可的文档形式，以保证所有涉众都能很容易地理解这些文档。
 4>应该把架构设计方案交由涉众阅览，应该让涉众积极参与设计方案的评审。
 5>应该对架构认真分析，得出可应用的量化度指标（如最大吞吐量）。也应该对质量属性进行评估，以避免出现发现问题时为时已晚的情况。
 6>架构的设计应有助于增量的实现。为此，可以先创建一个粗略的、具备雏形但功能最简单的系统，通过把这个骨架系统逐步细化、扩大来得到所期望的系统。
 7>允许架构带来一定（少量的）资源争用，但应清楚地给出这些资源争用的解决方案、告之有关各方，并保证这个方案切实可行。如网络占用问题，设计师就要为每个开发小组制定出将网络占用减少到最低限度的指导原则。
关于结构的建议有：
 1>架构应该采用定义良好的模块，各模块的功能责任划分应基于信息隐藏和相互独立的原则。信息隐藏模块应该包括那些封装了计算基础结构特性的模块，以将大部分软件与计算基础结构的变化隔离开。
 2>应该使用特定于每个属性的众所周知的架构战术来实现质量属性。
 3>架构绝对不可以依赖某个特定版本的商业产品或工具。如果确实依赖某个商业产品，则要合理设计架构，使得当所依赖的商业产品发生变化时，能够方便、经济地适应。
 4>应将产生数据的模块和使用数据的模块分离开。未来的变化往往仅限于数据产生或者数据的使用，所以这样做一般可以提高系统的可修改性。
 5>对于并行系统，架构应该采用定义良好的进程或者任务，他们未必反映模块的分解结构。也就是说，有些进程运行涉及到若干模块，而模块中某个过程可能也要为若干个进程调用。
 6>每个任务或进程的编写都需要考虑到与特定处理器的关系，并保证能够方便地改变这种关系。
 7>架构应该采用少量的、简单的交互模式。即在整个运行过程中，系统的功能应该保持一致。这可使系统易于理解，有助于缩短开发时间、提高可靠性、增强可修改性。