[Restful_架构风格与基于网络的软件架构设计]阅读感想:软件架构思考组成

运行时抽象：

一个软件架构是一个软件系统在其操作的某个阶段的运行时（run-time）元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都有自己的软件架构。

软件架构的核心就是抽象原则：利用封装来隐藏一些实现的细节，从而更好的识别与支持系统的属性。这里就为我们指引了一个思考的方向，尽可能的对其它的组件或元素隐藏实现的细节，为关联的组件提供简单的公开接口，这样可以极大的降低系统各模块间的耦合性提高内聚的程度。这个说起来容易，但实际上在平时的项目中，却很少有去思考，我们的实现是否符合软件结构设计原则：开-闭原则。

软件架构是对系统运行时刻的一种抽象，看到这句话时，有一种恍然大悟的感觉，一直以来的感觉就是软件架构就是一种以文档的形式存在的设计，关注的就是固定的结构形式，从来没有想过架构本身的设计与思考过程的关注点是运行时系统的处理与协作过程，思考的过程也潜意识的以为只要关注于模块与模块之间的关系就可以解决蜘蛛网似的模块关联与代码的重复扩散，不能说这个是错的，但是是一种偏面的看法，如果一开始就将系统当成运行中的，关注于运行时刻的处理过程，会更容易的识别系统的约束与数据的处理过程，尽早的把问题暴露出来，而一开始只关注于模块的关系，只能说从软件结构上的解决问题。但更多的问题却不能发觉。

元素：

一个软件架构由一些架构元素（组件、连接器和数据）的配置来定义，这些元素之间的关系受到约束，以获得想要得到的一组架构属性。

我们会经常思考组件与组件之间的关系，往往只是用直白的一条线条或者一个箭号来代表它们是有联系的，比如是依赖，是聚合或者说是组合的关系，但这样就可以了吗？在以前一直都是这样以为的，这样足够了，但是没有意识到，我们放了一条线条上去，但是在实现时又如何去表达呢？其实没有很晰的表达，多数都是直接的属性依赖关系，但很多时候，关系并非如此的简单，例如，组件1与组件2存在协作的关系，但是数据的入口类型并不统一，只能用另外的一个封装器来封装这两者之间的协作关系，这个封装器就是一种连接器的表达。也许这个不是必要，但是我们仍然需要去考虑，这样子做是否会更好。数据，我们经常勿视了这么一个元素，因为从来都没有从运行时的角度思考过，当然很少会涉及到数据的本身，或者说被所谓的面向对象大法给迷住了，但数据本身确实有很多地方需要我们去关注，怎么样的数据才能更好的处理，数据的变动会给各个层面上的程序造成什么影响？