软件架构的典型组成部分-程序组织

系统架构首先要以概括的形式对有关系统做一个综述。如果没有这种综述，要想将成千的局部图片（或十多个单独的类）拼成一幅完整的图画是相当伤脑筋的。如果系统是小小的只有12块的智力拼图玩具，你那一岁的小孩也能在眨眼的功夫解决它们。不过吧12个子系统拼到一起就要困难一些啦，而且如果你不能将它们拼起来，那么就无法理解你正在开发的这个类对系统有何贡献。

在架构中，你应该能够发现那些曾经考虑过的对最终组织结构的替代方案的记叙，找到之所以选择最终的组织结构的方案的理由。如果对某个类在系统中的角色没有一个清晰的构思，那么编写这个类就是一件令人灰心丧气的工作。描述其他组织结构，才能说明架构最终选择这种组织结构的缘由，并且表明各个类都是慎重考虑过的。有一份对设计实践的综述发现，维护“设计缘由”与“维护设计本身”一样重要。

架构应该定义程序的主要模块。根据程序规模不同，各个模块可能是单个类，也可能是由许多类组成的一个子系统。每个模块无论是单个类还是一组协同工作的类或者子程序，他们共同实现一种高层功能，诸如与用户交互、显示Web页面、解释命令、封装业务规则，访问数据等等。每条列在需求中的功能特性都至少应该有一个模块覆盖它。如果两个或者多个模块声称要实现同一功能的话，那么他们就应该是相互配合而不会冲突。

应该明确定义各个模块的责任。每个模块应该负责某个区域的事情，并且对其他模块的事情知道的越少越好。通过使各个模块对其他模块的了解达到最小，你能将设计的信息局限于各个模块之内。

应该明确定义每个模块的通信规则。对于每个模块，架构应该描述它能直接使用那些模块，能间接使用那些模块，不能使用哪些模块。