什么是架构机制?
架构机制是针对通用问题的通用解决方案,在开发过程中使用可以减少开发的复杂程度。它们代表了在解决方案中将被标准化的关键技术概念。架构机制促进了系统关键架构方面的演进。它们使团队可以维持一个有凝聚力的架构,使细节实现延迟到到真正需要的时候。
架构机制被用于满足关键架构需求。通常,这些需求是非功能需求,如性能和安全问题。完全描述的架构机制显示了软件中的结构和行为模式。它们形成了软件的公共基础,并将在整个产品开发中被持续的应用。它们也形成了软件的标准化工作方式的基础。因此,架构机制是整个软件架构中的一个重要元素。对架构机制进行定义也将促使做出决策,是否能够利用现有的软件组件来提供需要的行为,或者是否需要购买或构建新的软件。
定义架构机制的价值:
-
显示的定义系统中常见的解决方案机制,有助于制定计划。
-
为开发者们记下标记,以使他们一次性构建系统标记方面,然后重用它们。这将减少重复工作。
-
促进开发一组一致的服务。这将使系统更容易维护。
架构机制包含三个状态:分析、设计和实现。它们反映了机制描述的成熟度。在软件工作中,随着 架构关键需求 的不断完善,架构机制的状态将沿水平方向变化并不断暴露新的细节。。
架构机制的状态
状态
|
描述
|
分析
|
针对常见技术问题的概念解决方案。例如:持久存储是针对存储数据的通用需求的一个抽象解决方案。该状态的用途是简单的识别一个需要被设计和实现的架构机制,并捕获此机制的基础属性。
|
设计
|
将分析机制细化到某个具体的技术(如RDBMS)。该状态的用途是指导精确的产品或技术选择。
|
实现
|
将设计机制进一步细化为软件规范。这可以表达为一个设计模式或样例代码。
|
有关这些不同类型机制的进一步信息,参见附加的概念材料。
请注意,这些状态经常被称为分析机制、设计机制和实现机制。它们只不过是表达了架构机制在开发中的不同状态。从一个状态转换到另一个状态,经常很明显或直观,可以在几秒内实现。但也可能需要更多的分析和设计,而花费更多的时间。重要的一点是这些不同类别的机制其实是同一概念的不同状态。其区别仅仅是补充或细节。
下图说明了架构机制的状态转换:
架构机制状态机
架构机制中需要捕获什么信息?
每一类/状态架构机制所捕获的信息是不同的(即时这些信息看起来像是另一个的补充):
-
分析机制, 为机制命名,给出概要描述以及从项目需求继承而来的某些基本属性
-
设计机制, 更加具体,并假设某些实现环境的细节
-
实现机制, 为每个机制给出准确的实现
初始时识别的机制,对于团队来说被看做一个标识,“我们将以标准的方式来处理系统的这个方面。我们将在后续补充完善。” 在项目进行过程中,架构机制被逐渐补充完善,直到成为系统的一部分。
分析机制
分析机制是架构机制的初始状态。它们在项目的早期被识别,并被作为未来软件开发的书签。它们使团队专注于需求,而不会因复杂的实现细节被分心。通过浏览需求并寻找经常出现的技术概念来发现分析机制。安全、持久存储和遗留接口是其中的一些例子。实际上,分析机制是整理和汇集了描述架构关键主题需求的一份列表。这使它们更容易管理。
分析机制被简单的描述为:
一旦定义了分析机制的列表,就可以依据迭代目标划分优先级并进行细化。没有必要一次性开发所有的分析机制。更明智的方式是,仅仅开发那些支持当前迭代中要交付功能所需要的分析机制。
设计机制
设计机制代表了使用哪些具体技术开发架构机制的决策。例如,决定使用关系数据库管理系统进行持久化存储。通常,没有比这更复杂的了(当然,制定决策所花费的努力有时相当复杂)。
关于何时将架构机制从分析状态细化到设计状态的决定有很大的随意性。通常,在项目组中存在某些约束强制了这些决策。例如,可能存在企业数据库标准,这意味着关于持久化存储机制可以在项目的第一天就决定下来。
在其它一些场合中,该决策可能指向项目团队尚未获得的产品。如果是这样,需要及时作出决定以使团队能够获得所需的产品。
通常,开发一些原型代码来验证这些决策的合理性对开发是有益的。架构师应该自信所选择的技术能够满足需求。对应的分析机制的属性应该作为准则来验证该决策的正确性。
实现机制
实现机制确定了架构机制的实际实现(因此得名)。它能够被模型化为某个设计模式或是提供样例代码。
生产实现机制的最佳时间是开发计划中第一次需要此功能的时候。架构师和开发者共同开发。
关于在机制中能够捕获的各类信息,参见:Example:架构机制属性.
|