通往弹性软件架构之路

从平台无关的结构开始

如何结构化系统的方法是一个重要的架构决策，通过这个方法将使系统关注点保持相互分离。首先，从平台无关的角度进行结构化，然后根据平台特征来完善系统。平台无关的结构化是功能需求驱动的（如用例建模）。

用来实现弹性结构的工具有：类和用例。类有助于确保系统中的单元互相独立，用例则可以保持每个单元的任务互相独立。因此，系统中就有了两个正交的结构――元素结构和用例结构。

元素结构揭示了系统的元素在元素命名空间中的位置。一般通过层（layer）、包、类以及类中的特性来构建层次化的元素结构。

用例结构定义了在元素结构上实现功能的方法。它包括了切片(slice)――用例切片(use-case slice)和非用例特定切片(non-use-case-specific slice)，这些切片把实际的类和类特性增加到元素结构上。

如果想让元素结构和用例结构都保持弹性，这意味着如果发生需求变更，造成的影响应该局限到元素结构中少量的包和类中；同时该影响也应该局限到少数的用例切片。局限意味着少量的改变，并且这些改变不会在那些需要变化的包和用例切片之外传播。

元素结构

一个模型的元素结构是基于包和类的分层结构，它唯一标识了每个元素。由于目标是实现弹性结构，自然会将相同用途的类放在一起。

层（Layer）。一般在模型中用层来作为第一个层次的划分方法。层用来对抽象出来的同一级软件元素进行分组。将更抽象及可重用的元素放在下面的层中，而把更具体的或者是很少重用的元素放在上面的层中。通常，使用两个高级别的层就足够来分析系统的功能性需求：

应用层。应用层包含了这些元素，它们实现了用例中支持系统的主要参与者的工作流。应用层中的元素通常用领域层中的元素来实现用例。你可以按照以下准则来组织应用层中的包：

◆支持一个或者多个特定参与者的类。

◆涉及一个或者多个特定用例的类。

◆涉及系统某些功能区域的类。

领域层。领域层包含了描述重要领域概念的元素。它们捕获了系统中需要维护、跟踪或者控制的信息以及产生这些信息的相关行为。这些元素通常在用例实现中被共享，它们更经常被重用，因此处于比应用层更低的层中。尽管如此，由于它们被用例实现（use-case realization）共享，因此用例实现经常横切这些领域元素。

用例结构

如上所述，元素结构只是简单地识别命名空间中的元素，是用例结构中的切片为每个元素加上了实际内容。共有两种切片：用例切片和非用例特定切片。

按照惯例，一般采用纵向来表示元素结构（包含的层，包和类），这样在顶端有应用特定层和包，在底端有应用无关的层和包。为了强调和用例结构的正交性，我们采用横向结构来表示用例结构，左边是非用例特定切片，右边是用例特定切片。

叠加平台特性

在每天结束的时候，你正在构建的系统必须能在某个目标平台上运行，还需要加入一些用户接口。如果需要提供高处理能力，必须将处理分布到所有的处理节点中。分布性就是平台相关的。必须为系统所管理的信息提供固定的存储空间，可能还需要和遗留系统整合。因此，你会发现平台特性贯穿于整个用例实现中，不管这是应用用例还是基础结构用例。

选择平台

系统的平台特性基于架构师选定的部署结构(deployment structure)和进程结构(process structure)。

保持平台特性独立

即便选定了部署和进程结构，仍然还有很多平台具体的实现技术需要选择。必须明确的是，不要被束缚在特定的执行平台上或特定的供应商上。平台特定技术总是不断发展，不断推陈出新。如果更改设计只是为了跟上这些技术上的变化，那是非常有害的。因此，必需使平台特性保持独立。如果从用例设计中把这些平台特性剥离出来，剩下的就是最小化用例设计（minimal use-case design）了。这个最小化用例设计有以下特征：

◆它是可执行的，并且采用一种默认的编程语言实现，如Java。

◆它在通过程序接口来激活的。一个单独的程序来触发该最小化用例。通过这种方式，所有用户接口、信息的表示，和数据的输入机制都从最小化用例的设计中分离出来了。

◆分布性、内部进程的通信和平台相关消息通信等关注点都与最小化用例设计保持分离。所以，虽然事实上最小化用例设计在先前说明的所选平台上运行，但是它看起来是运行在单一节点、单一进程和单一线程上。

◆它所需要的所有信息都在内存中。通过这个方式，所有与留存机制（持久性）相关的关注点都不在该最小化设计中。同样，参与者实例的每个活动都是原子性活动。

其它的所有东西（用户界面，分布等）都被认为是平台特性相关的，并且被单独设计，叠加在最小化用例设计的上层。

把平台特定部分从最小用例设计中分离出来有很多好处。首先，最小化用例设计变得更加简洁。任何一个懂得指定编程语言的人都可以开发它，而不需要知道所有的平台特性。最小用例设计容易设计和开发，让你很容易生产出一个可执行产品。更加容易测试，因为它不需要具有平台特性的测试环境。

总结和强调

在项目的早期建立一个弹性架构是至关重要的，其目标是让系统健壮并且减少需求变化所带来的冲击和系统大量的修改。它同时也让系统变得容易理解。从面向方面的观点看，一个弹性系统让你更容易定义pointcut，因为需要扩展的所有类和职责都被局部化了。

建立描述系统的模型结构的过程是迭代的。首先从一些平台无关的结构开始，然后开始逐个分析架构重要的用例。这么做的时候，会逐渐补充和完善已经存在的结构，并且将平台相关的元素融合到结构中。当遍历了所有的架构重要用例，就可以建立一个相当有弹性的架构。

查看本文来源