13

其中的关键核心点是，不同涉众的关注点的分割。我有我自己的关注点，你有你的关注点，不同的关注点汇聚到一起，而关注点背后代表的是一种人的观点，这些人就构成了不同的涉众，然后在不同的涉众里面，他们之间会有一些各种各样的关系，这些关系之间是如何交互的，这就构成了一个模型。

其实，模型是用来表示，各个涉众，各个关注点，以及他们代表的事物之间的关系的。

对一个观察者来说，他观察了一个主题，或者一个物体，一个subject，而这个观察者他观察这个主题的时候，肯定是想了解清楚这个主题，搞清楚他要观察的对象是什么，他要解决的问题是什么。作为观察者，他之所以去观察，一定会有一个问题来引导他去观察，或者说，对观察者来说，他想回答这个问题，所以他才关注这个问题，他的目的就是想得到的答案。

我们可以使用一个模型，来描述这个观察者的一系列过程，而标识它的这个过程肯定不仅仅只有一个模型，但我们使用的模型，是抽象了主题里面的所有东西的一个模型，这也就是该模型是一个主题的模型，这个时候，才尽可能的表达出真实的意图，从而能够把误差控制在可以接受的范围之内。

14

然后，这个Model，这个M就是这个模型的观察者。

我一再强调，所有的模型不可能完全代表事实本身，它一定是和事实有偏差的，甚至是有些误差的，在这个模型内，描摹真实世界是不可能的，这个数值内任何数据都有误差，模型的好坏，不在于消除误差，而在于是否可以满足在可接受的误差范围之内。

其实对于大部分工程过程来说，尤其是对于整个软件的开发来说，大多数下，都可以归属于是模型驱动的软件开发过程。

通过模型驱动的软件开发过程，然后我们最终获得设定的战略设想，然后把这种设想，做成了一个模型。所以说，架构它的思想的表达方式，就是去设计模型，设计出能够表达我们战略设想的模型。

然后让我们通过模型，表达出了人、事、物、规则之间的关系，我们的架构最终导向到模型驱动的架构，然后我们能通过使用模型驱动的架构，来驱动我们的软件开发过程。

15

当然，就概念上来讲，软件架构，并不仅仅只有模型驱动的架构。

模型驱动的架构，也只是一种架构的风格，风格有多种多样，选择不同的架构风格也是要看不同的企业环境，我们之所以选择模型驱动的架构来描述，这也只是为了更好的表达架构思想而已。

架构的风格是为系统的架构信息提供战略设想的。

这个设想的第一步就是，先想清楚一下我们的风格是什么，再去选择哪些架构的风格，甚至是需要你去创造架构的风格，而我们最终选择了模型驱动的架构风格。我又融入了很多的概念，你可以把它当成一种世界观一种方法论，我们另外选择的是，面向对象的一种架构的风格。比如，CS（客户服务器结构），这都是我们架构的一种风格，你一旦了解清楚了需求（requirements），要做的一件事情就是，来选择一种风格，来有效的设计你的需求。

怎么选的架构模式，当然不是凭空设想，而是脚踏实在，也不是随机胡乱的组合，而是政治、经济和斗争的结果中间寻求的一种平衡，然后根据这个平衡，再选择这样一种架构的风格。

16

高度决定我们的视野，你只能站在这样的高度上，在充分理解了你的环境以及上下文之间的关系上，然后再去发现，分析，与解决问题。

用我们的话说，我们不同的人，因为层次不同，所看到的世界也是不一样的，这是因为他的关注点不同造成的。

而架构，在一个软件项目中，是在最高级别在思考与设计，考虑这一系列问题的。它一定要关注一些很多很多互相关联的事情，一定要对不同涉众者的关注点的分割，也就是说，一个总裁的关注点肯定和一个员工的关注点是不一样的，这里并不是歧视不同的员工，当然总裁也是员工，而是说，人在企业中的身份与分工，必定会导致他们看待问题的角度是不一样的。

换句话说，我们要通过不同涉众的角度的不同，来区分与分隔这些关注点。

架构师，在一个项目组里，他是一个team的成员，当然有些项目比较简单的话，也不需要架构师。当你们项目中有架构师的时候，祝贺你，这说明你们的系统比较先进了。因此，架构师是一个系统的设置。

17

关于系统的质量问题，我们分成两部分，一个是开发时的质量，一个是运行时的质量，设计模式这个可以解决一个重要的quality，那就是软件开发的质量。质量本身就包括可扩展性，这可以通过设计模式的方式来很好的表达。

我们简单的介绍几个设计模式的原理。

(1)、开闭原则（Open Close Principle）

OCP就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

(2)、里氏代换原则（Liskov Substitution Principle）

这是面向对象设计的基本原则之一。任何基类可以出现的地方，子类一定可以出现。

LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。LSP是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以LSP是对实现抽象化的具体步骤的规范。

(3)、依赖倒转原则（Dependence Inversion Principle）

DIP是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

(4)、接口隔离原则（Interface Segregation Principle）

ISP使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿可以看出，设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。目标是：降低依赖，降低耦合。

(5)、迪米特法则（最少知道原则）（Demeter Principle）

DP是，一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

(6)、合成复用原则（Composite Reuse Principle）

CRP是尽量使用合成/聚合的方式，而不是使用继承。

这些原理，都是概念的载体，就是怎么样才能达到我们的可扩展性，例如可以通过某个具体的设计模式来提供一种做法，但前提是，要了解这些设计模式适用的情景，也就是你要搞清楚你想要干什么。

18

我们的架构框架，要解决一个首要的问题，就是谁来使用你的软件。

你要找出来系统的涉众。每一个涉众都有很多，所以要进行分割。分割出来的结果就一个关注点。

一个涉众，通过不同关注点构成一个集合，不同的集合根据汇总与综合，根据业务的特点，我们把它做成一个模块，然后这些不同模块互相配合，构成了这样的一个软件系统。

我们的系统，有不同的涉众，有不同的关注点，不同的集合，不同的模块，就相当于每个人都有自己的事业，而涉众就是一个人对应的关注点。因为每个人的关注点是不一样的，而不同的涉众都有他的利益点，或者说都有他自己的看法，因此不同的涉众，他拥有的关注点就会不同。

我们架构师，就是通过抽象来分析这些关注点，然后给它取了一个名字就叫涉众。不同的人就需要有不同的涉众，然后又对应不同的视点，这些不同视点又组成了一个完整的整体。

所以我们必须要定义不同视点，以及视点之间的对应关系，也就是要确定不同的规则、议事，各种人事物，责权利的规则，这都要理解清楚，这我们前进的目标，不然，你也没法进行工作了。

很多软件相关专业的学生，在他们的大学课程里，项目管理、需求分析等等都学了，但去公司里工作时发现没用，这是因为全是书本上的，没有实践经验，完全是理论，这基本等于没学。因为，在真实的企业里，不但有技术因素，还有经济因素，当然还有政治斗争因素，我会告诉你这就是现实，我们不需要解释为什么这样。

企业里面，对刚毕业的学生来说，就是个初级新手，你就得接受这样的环境，要不你就离开，庙小装不下大神，走人吧。因此，为了模拟出现实的真实性，我们必须弄一个真实的商业系统，把理论和实践融入到系统的架构过程中，这可以很好的体现出我们的思想路径。