架构设计中的方法学(8)——架构愿景（2）

答案：     我们从源自需求模式中，学习到架构的设计是来自于需求的，而应用于软件全局的架构则来自于最重要的需求。还记得我们在那个模式中提到的网上宠物店的例子吗？系统采用了MVC模式，sun的官方文档一开始说明了为什么采用MVC模式，MVC模式解决了什么问题，然后开始分析MVC模式的几个组成部分：Model、View、和Controll。其实，MVC中的每一个部分，在真正的代码中，大都代表了一个子系统，但是在目前，我们就非常的清楚系统大致上会是一个什么样子，虽然这时候它还十分的朦胧。 
  
  不要视图在全局的架构愿景中就制定出非常细致的规划，更不要视图生成大量的实际代码。因为，你的架构愿景还没有稳定（我们在其后的稳定化的模式中将会讨论稳定的问题），还没有获得大家的同意，也没有经过证明。因此，从整个的开发周期来看，全局架构愿景是随着迭代周期的进行不断发展、修改、完善的。 
  
  我们如何确定全局架构愿景工作的完成？一般来说，你的架构设计团队取得了一致的意见就可以结束了，如果问题域是团队所熟悉的，一两个小时就能够解决问题。接下来设计团队把架构愿景传播到整个的开发团队，大家形成一致的认识，不同的意见将会被反馈会来，并在本次的迭代周期（如果时间比较紧迫）或下一次的迭代周期中（如果时间比较宽松）考虑。 
  
  子模块级、或是子问题级的架构愿景 
  
  这时候的架构愿景已经是比较明确的了，因为已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差不多，具体的例子我们也不再举了。但是要注意一点，你不能够和全局愿景所违背。在操作上，全局愿景是设计团队共同制定出来的，而子模块级的架构愿景就可以分给设计子团队来负责，而其审核则还是要设计团队的共同参与。这有两个好处，一是确保各个子模块（子问题）间不至于相互冲突或出现空白地带，二是每个子设计团队可以从别人那里吸取设计经验。 
  
  在设计时，同样我们可以参考其它的资料，例如相关的模式、或规范（界面设计指南）。在一个有开发经验的团队，一般都会有开发技术的积累，这些也是可供参考的重要资料。 
  
  我们在这个层次的愿景中主要谈一谈子模块（子问题）间的耦合问题。一般来说，各个子模块间的耦合程度相对较小，例如一个MIS系统中，采购和销售模块的耦合度就比较小，而子问题间的耦合程度就比较大，例如权限设计、财务，这些功能将会被每个模块使用。那么，我们就需要为子模块（子问题）制定出合同接口（Contact Interface）。合同的意思就是说这个接口是正式的，不能够随意的修改，因为这个结构将会被其它的设计团队使用，如果修改，将会对其它的团队产生无法预计的影响。合同接口的制定、修改都需要设计团队的通过。此外，系统中的一些全局性的子问题最好是提到全局愿景中考虑，例如在源自需求模式中提到的信贷帐务的例子中，我们就把一个利息计算方式的子问题提到了全局愿景中。 
  
  代码级的愿景 
  
  严格的说这一层次的愿景已经不是真正的愿景，而是具体设计了。但是我们为了保证对架构设计理解的完整性，还是简单的讨论一下。这一个层次的愿景一般可以使用类图、接口来表示。但在类图中，你不需要标记出具体的属性、操作，你只需要规定出类的职责以及类之间的相互关系就可以了。该层次愿景的审核需要设计子团队的通过。 
  
  而设计细分到这个粒度上，执行愿景设计的开发人员可能就只有一两个左右。但是比较重要的工作在于问题如何分解和如何归并。分解主要是从两个维度来考虑，一个是问题大小维，一个是时间长短维。也就是说，你（设计子团队负责人）需要把问题按大小和解决时间的长短分解为更细的子问题，交给不同的开发人员。然后再把开发人员提出的解决方法组合起来。 
  
  
  架构愿景的形成过程
  
  
  架构愿景的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。比如说，系统的特点是一个交互式系统，还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后，按照需求的重要性来设计架构愿景。 
  
  架构愿景的设计并不需要很复杂的过程，也不需要花费很多的时间。我们已经提过，架构远景的主要目的就是为了能够在开发团队中传播设计思路，因此，架构愿景包括基本的设计思路和基本的设计原则。 
  
  值得注意的是，架构远景可能会有多种的视角，下文讨论了一种设计模式的视角。但是实际设计中还可能会基于数据库来设计架构愿景。但在企业信息系统的设计中，我推荐使用领域类的设计，也就是下文中讨论的例子。 
  
  架构愿景设计好之后，问题的焦点就转到如何传播架构愿景上来，为了达到在开发团队中取得统一设计意图的效果，可以考虑援引团队设计模式。除此之外，针对性的项目前期培训也会是一种有效的做法。 
  
  使用架构模式 
  
  架构模式也是一种很好的架构愿景设计思路的来源。随着对设计模式的研究的深入，人们发现其中的一些设计模式可以扩展、或变化为软件设计的基础。在这个基础上再实现更多的设计，这些模式就形成了架构模式。当然，不同的软件，它们的架构模式也是不一样的。在《Applying Pattern》一文中，有一个很典型的架构愿景的例子： 
  
  假设我们需要设计分布式的交互式系统。分布式系统和交互式系统都有特定的架构模式，前者为Broker模式，后者为MVC模式。首先我们先要根据系统的特点的重要程度来排列模式的顺序。这里假设需求中分布式特性更重要一些。那么我们首先选择Broker模式作为架构的基本模式： 
  
  
  再考虑交互式的特点，根据MVC模式的特点，我们需要从目前的基本架构中识别出Model、Controller、以及View。Model和View都很简单，分别分布在上图中的Server和Client中。而Controller则有两种的选择，假设这里的Controller部署在客户端，上图则演化为下图： 
  
  
  这样，基础的架构愿景就已经出现了。如果我们还有更多的需求，还可以继续改进。但是，记住一点，架构愿景不要过于复杂。正如我们在上一节中所讨论的，这里我们虽然是基于设计模式来讨论架构愿景，但是实际中还有很多从其它的视角来看待架构愿景的。至于要如何选择架构愿景的视角，关键的还是在于需求的理解。 
  『引自 IBM DW中国』 

上一个：“简”话设计模式(1)
下一个：架构设计中的方法学(8)——架构愿景（1）