初探架构，随笔整理

软件架构在描述什么？

软件架构描述的对象是直接构成系统的抽象组件。

软件架构相关方有哪些？

软件架构师，客户，老板，软件工程师，程序员。

软件架构师的职责？

软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序员商谈实现技巧，外观和风格。

定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

怎样定义软件架构？

一段程序或系统是有一个和多个包含了元素，元素的对外可用的属性，及它们之间关系的架构组成。

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

“外部可见” 的属性是指可用通过其他元素生成一个新的元素。比如：提供服务，定制服务，错误处理，资源共享等。

“Externally visible” properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.

软件架构定义了什么？

首先，定义元素，明确的元素与元素直接相互之间的关系，忽略与元素无关联的细节。因此，架构是一个系统的抽象，对与元素细节的忽略不会影响元素的使用，关系。现有系统中的元素之间关系的调用是通过有意义的接口来隔离。

其次，明确系统的职责与结构的组成部分。架构是有不同职责的结构组成的。一种结构不能代表架构。

第三，每一个系统都有自己的架构，没有必要将一定跟随其他已知的架构。每一个系统的架构都是独立存在的。

第四，定义每一个元素的行为。在整个架构内元素的行为将被其他元素观察，发现。这种行为将元素进行有效的连接。

最后，架构没有好，坏之分。一个系统的框架都有自己的行为，所要呈现的不同内容及生命周期。

Assuming that we do not accept trial and error as the best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and hoping for the best。

假设我们不接受在检验和错误是选择一个系统架构的最好方式，那么就随机选择一个，希望它是最好的吧。