粒度多样性与相对性下的架构归属

“软件系统的架构”这个常见说法容易让人误以为只有完整的软件系统才有架构，但真实的软件其实是”由组件递归组合而成”的——可以用Composite（组合）模式来刻画这个结构：组件的粒度可以很小也可以很大，任何粒度的组件都能组合成粒度更大的整体（粒度多样性）；组件粒度的界定必须放在具体的实践上下文中才有意义，你眼中的大粒度组件，对另一个上下文而言可能只是原子组件（粒度相对性）；组件分为原子组件（在特定实践上下文中不可再分）和复合组件（由其他原子或复合组件组合而成）两种，无论哪种都可以通过交互完成更复杂的功能。由此可以给”软件架构”找到更准确的位置：架构设计针对的是作为复合整体的”复杂软件单元”，只要一个单元足够复杂、需要做出重要的组织与决策，它就值得有自己的架构——系统、子系统、框架（Framework）根据实际需要都可以进行独立的架构设计，而不是只有顶层系统才配拥有架构。书中给出两个对照案例：航空航天领域的系统往往极为复杂，总系统需要系统架构师，子系统有时也单独配备架构师；用友华表Cell组件对使用者而言只是”开盒即用”的原子组件，但它的研发团队同样完整经历了需求分析、架构设计、程序开发的全流程。这条逻辑延伸到SOA（面向服务架构）与CBSE（基于组件的软件工程）场景时尤其关键——整个系统的架构模式可以是SOA，而每个服务组件本身也有自己独立的架构设计，不了解这一点、把”组件内部”当成理所当然的黑盒不去审视，在实践中是很危险的。