本文转自：http://www.cnblogs.com/hegezhou_hot/archive/2010/09/18/1830306.html

一、上章回顾

在上篇中我们讲解了几类UML2.0语言新推出的建模图形,总体来说通过这些图形能更详细的将某类信息表达出来。在这里我们简单回顾上篇讲解的内容。

上图中已经简单介绍了上章讲述的内容，具体内容请看：系统架构师-基础到企业应用架构-系统建模[下篇]。

二、摘要

本章将主要的简单介绍在系统架构中的设计模式及相应规范准则。并结合相应的代码来说明如何遵循系统架构中的一些基本的设计规范及准则。而我们将在本文介

绍几类常用的设计规范，我们先来看看结构化设计的二个基本原则：

当然既然提出了基本的准则，那么我们如何来满足准则呢，并且能更好的设计呢？我们可以通过如下手段来达到这样的要求：

 当然图中演示了功能分离的策略，通过把需求按照不同的功能详细的划分开来，每个功能都是独立

的，当然我们这里也可以成为是关注点。下面我们将针对这些原则进行详细的讲解。

三、本章内容

1、上章回顾。

2、摘要。

3、本章内容。

4、设计规范及原则。

5、如何满足设计要求。

6、本章总结。

7、系列进度。

8、下篇预告。

四、设计规范及准则。

1、高内聚

首先我们来看看内聚的含义：软件含义上的内聚其实是从化学中的分子的内聚演变过来的，化学中的分子间的作用力,作用力强则表现为内聚程度高。在软件中内

聚程度的高低，标识着软件设计的好坏。

我们在进行架构设计时的内聚高低是指，设计某个模块或者关注点时，模块或关注点内部的一系列相关功能的相关程度的高低。

例如：下单模块：

 一般情况下，下单模块都会有如下的信息，订单的信息，产品的信息及谁下的单(买家信息)。这是基

本的，那么我们设计的时候就要把相关的功能内聚到一起。当然这是从大功能(下单管理)上来说，当然这些模块还可以再细化分成产品、订单、会员等子模块。

例如我们在设计数据库操作辅助类提供的方法有：

 通过这样的方式，那么这个组件只负责数据库操作。这样带来的好处也是显而易见的。高内

聚提供了更好的可维护性和可复用性。而低内聚的模块则表名模块直接的依赖程度高，那么一旦修改了该模块依赖的对象则无法使用该模块，必须也进行相应的修改才

可以继续使用。

低内聚的模块设计的坏处有：首先模块的功能不单一，模块的职责不明确，比较松散，更有甚者是完成不相关的功能。这样的设计往往是不可取的。可以通过重

构来完善。

下面我们来说下高内聚的简单解释：什么样的模块算是高内聚，并且能够在系统中很好的使用。

那么我们在设计的过程中如何去完成高内聚呢？

以上基本上讲述了高内聚的好处，并且阐述了如何实现高内聚的步骤和原则。下面我们来说说可能高内聚带来的坏处。

高内聚有时候也不是说所有的情况都采用这样的原则，当然高内聚还是要适度的，下面来举例说明：例如内聚性要求强的话就像Windows32中系统提供的

API，里面的函数太多了，都放在一个Dll中，那么每个函数完成一个功能。这样强大的功能，会比较复杂，所以并不是完全的高内聚越高越好，还是要看实际的需要。

当然维护起来也不是特别的方便。

2、低耦合

首先我们来看看低耦合的定义：低耦合是用来度量模块与模块直接的依赖关系。耦合当然也可以这样简单的理解，我想懂电脑的应该都知道，CPU与主板之间的

关系，CPU如果是特殊的CPU必须使用特殊的主板来支持，那么如果说这个CPU不唯一依赖唯一主板，那么就认为这个CPU与主板的关系是低耦合的关系。

下面我们来举例说明低耦合的设计与高耦合的设计：

 这是一个简单的低耦合的设计，电器与插座之间是低耦合的关系，就算我替换了不同的插座，电器依

然可以正常的工作。因此简单的描述如下，就是A模块与B模块存在依赖关系，那么当B发生改变时，A模块仍然可以正常工作，那么就认为A与B是低耦合的。

1、笔记本接音响可以正常的使用。

2、笔记本接专配耳机正常的使用。

对应一般的音响来说，笔记本是通用的，音响和笔记本直接的关系是低耦合的，但是笔记本和耳机却是高耦合的，只有专配的耳机才能和笔记本互联使用，而不

是通用的，所以说笔记本和专配耳机存在着较强的依赖关系。当然最简单的方式就是笔记本提供统一的耳机接口，可以满足一般性的需求。

下面我们将来分析如何构建低耦合的设计。

总结

上面我们已经讲解了低耦合和高内聚的二个原则，通过这2个原则我们知道，满足这2个原则是衡量一个架构设计好坏的一个参考标准。下面我们将来讲解通过

功能分离的方式来满足上面的2个原则。

五、如何满足设计要求

1、如何按功能进行模块化的分离。

我们在将一个系统进行功能划分时，我们一般如下来进行：

首先、我们先把功能职责划分成独立的单元。

例如现在有个B2C系统，那么我们按照B2C的需求，如下分析：

 我们这里简单的分析下B2C应该具有的功能模块，当然这些模块的划分中，有些模

块还可以继续的分离，当然我这里只是实例分析出来。

2、对分离出来的模块化进行抽象，例如我们以支付为例。

 这里通过支付接口向外提供服务。那么外界模块不关心支付系统模块的变化，只需要调用接口

即可，如果具体的支付方式，比如支付宝的方式发生改变，在调用支付服务的模块中也不需要做任何的修改就可以正常的提供服务。显然这样的方式是不错的实现方

式。

通常情况下我们在系统分离式只是以接口的方式提供服务，供其他的模块进行使用。在模块内部有大量的信息是不要向外部暴露的，所以模块在设计时访问域的定

义就要划分好，防止因为访问域的定义而对模块的信息造成破坏。

下面我们来看下功能分离在不同的设计理念下都是什么样的表现：

上面只是实体性的分析了功能分离的好处及应用的广度，当然我们在后续会结合实例来讲解如何来实现这样的软件设计模式。当然这只是软件的架构设计，那么如

果细化到具体的实现呢？我们如何去设计每个功能点呢？这就是下章我们要讲解的内容了，那么本文先列出二种常见的方式。

下篇我们将针对设计原则中的实现方式，进行详细的剖析与具体实现进行举例讲解，希望大家多提意见。

六、本章总结。

本章中主要简单的讲述了软件设计的二个基本的规范与原则：

1、高内聚：描述了模块内部的一系列功能的相关程度,对于功能之间相关度不高或者根本没有相关性的功能包含在模块中的做法是不可取的。

2、低耦合：描述了模块直接的依赖、感知程度，耦合的衡量标准是从低到高，一般来说耦合度越低越好。

当然有些特殊情况下，可能这二个原则也有矛盾的地方，当然我们还是要根据项目的实际需要及情况进行抉择，当然这二个原则是为了设计提供更好的扩展性、

可读性、可维护性、极高的可复用性，所以要求我们在设计时尽量去满足这二个基本原则。而帮我去达到这二个准则的途径就是通过功能分离及细化来实现这样的准

则。下一篇我们将深入的分析与举例来说明实现这二个原则的各种规范及准则。

七、系列进度

前篇

7、系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]

8、系统架构师-基础到企业应用架构-设计模式[上篇]

9、系统架构师-基础到企业应用架构-设计模式[中篇]

10、系统架构师-基础到企业应用架构-设计模式[下篇]

中篇

11、系统架构师-基础到企业应用架构-企业应用架构

12、系统架构师-基础到企业应用架构-分层[上篇]

13、系统架构师-基础到企业应用架构-分层[中篇]

14、系统架构师-基础到企业应用架构-分层[下篇]

15、系统架构师-基础到企业应用架构-表现层

16、系统架构师-基础到企业应用架构-服务层

17、系统架构师-基础到企业应用架构-业务逻辑层

18、系统架构师-基础到企业应用架构-数据访问层

19、系统架构师-基础到企业应用架构-组件服务

20、系统架构师-基础到企业应用架构-安全机制

后篇

21、单机应用、客户端/服务器、多服务、企业数据总线全解析

22、系统架构师-基础到企业应用架构-单机应用(实例及demo)

23、系统架构师-基础到企业应用架构-客户端/服务器(实例及demo)

24、系统架构师-基础到企业应用架构-多服务(实例及demo)

25、系统架构师-基础到企业应用架构-企业数据总线(实例及demo)

26、系统架构师-基础到企业应用架构-性能优化(架构瓶颈)

27、系统架构师-基础到企业应用架构-完整的架构方案实例[上篇]

28、系统架构师-基础到企业应用架构-完整的架构方案实例[中篇]

29、系统架构师-基础到企业应用架构-完整的架构方案实例[下篇]

30、系统架构师-基础到企业应用架构-总结及后续

八、下篇预告。

下一篇将会已我们将深入的讲解功能分离的设计准则及实现方式，如何在设计中使用设计模式来构建满足高内聚、低耦合的功能模块等等。将通过实例化的方式对

每种原则及实现模式进行分析和举例。如果大家有好的意见和建议可以及时反馈，谢谢您的宝贵意见。

后语

希望看完本章的朋友可以从本篇中学到相应的软件设计规范，懂的人可以温习下相应设计准则，本篇希望能够抛砖引玉，希望大家能够多提出宝贵意见。由于是本

人平时工作中的理解与总结，不足之处再所难免，还请大家批评指出！如果您有什么意见或建议，请多多提出！大家的支持就是我的最大动力！