13
这其中的关键核心点是，不同涉众的关注点的分割。我有我自己的关注，你有你的关注点，不同的关注点汇聚到一起，这些关注点背后代表的是一种人的观点，这些人其实就是构成了不同的涉众，然后在不同的涉众里面，他们之间会有一些各种可样的关系，这些关系之间是如何交互的，这就构成了一个模型。
其实，模型是用来表示，各个涉众，各个关注点，以及他们代表的事物之间的关系的。
对于一个观测者来说。我们在这个问题上，这个观察者观察了一个主题，或者一个物体，一个subject，这个观察者它观察这个主题的时候，肯定是想了解清楚这个主题，搞清楚他要观察的对象是什么，他要解决的问题是什么。
作为观察者，他之所以去观察，他一定会有一个问题来引导他去观察的，或者说，对观察者来说，他想回答这个问题，所以他才关注这个问题，他的目标就是想得到的答案。
我们可以使用一个模型，来描述这个观察者的一系列过程，而标识它的这个过程肯定不只有一个模型，但我们使用的模型，是抽象了主题里面的所有东西的一个模型，这也就是该模型是一个关于主题的模型，这个时候，才尽可能的表达真实的意图，从而能够把误差控制在可以接受的范围之内。
14
然后，这个Model，这个M就是这个模型的观察者。
我一再强调，所有的模型不可能完全代表事实本身，它一定是和事实有偏差的，甚至是有些误差的，在这个模型内，描摹真实世界是不可能的，这个数值内任何数据都有误差的，模型的好坏，不在于消除误差，而在于是否可以满足在允许的误差范围之内。
其实对于大部分工程过程来说，尤其是对于整个软件的开发来说，大多数下，都可以归属于是模型驱动的软件开发过程。
通过模型驱动的软件开发过程，然后我们最终获得设定的战略设想，然后把这种设想，做成了一个模型。所以说，我们这个架构。它的思想的表达方式，就是去设计模型，设计出能够表达我们战略设想的模型。
然后让我们在这个模型里面。表达了人事物规则之间的关系，我们的架构最终是一位带着我们最终导向到模型驱动的架构，然后我们再使用这个模型驱动的架构，来驱动我们的软件开发过程。
15
当然，就概念上来讲，软件架构，并不仅仅只有模型驱动的架构。
模型驱动的架构，也只是一种架构的风格，架构的风格，有多种多样，选择不同的架构风格也是要看待不同的企业环境的，之所以，选择模型驱动的架构来描述，这也只是为了更好的表达架构思想而已。
架构的风格是为这个系统的架构信息和战略设想的。
这个设想的第一步就是，先清楚一个我的风格，而选择哪些架构的风格呢？
需要你去创造这个架构的风格，而我们最终选择了我们这个架构的风格，是一个模型驱动的架构风格。我又融入了很多的概念，这些概念又组成了一种世界观一种方法论，我们另外一个是面向一种架构的风格，比如，客户端服务器（cs）结构，都是我们架构的一种风格，然后当你一旦了解清楚了你的requirements，你要做的一件事情是，选择一种风格，来设计你的需求。
然后怎么选择架构模式，我上面的文章中已经提过，架构不是凭空设想，而是脚踏实在，也不是随机胡乱的组合，而是政治经济和斗争的结果中间寻求的一种平衡，然后根据这个平衡，再选择这样一种架构的风格。
16
高度决定我们的视野，你只能站在这样的高度上，在充分理解了你的环境与上下文之间的关系上，然后再去发现，分析，与解决问题。
用我们的话说，我们不同的人，因为层次不同，所看到的世界也是不一样的，这是因为他的关注点不同造成的。
而架构，在一个软件项目中，是在最高级别思考与设计，考虑这一系列问题的。
它一定要关注一些很多互相关联的事情，一定要针对对不同涉众者的关注点进行分割，也就是说，一个总裁的关注点肯定和一个员工的关注点是不一样的，我在这里不是歧视不同的员工，当然总裁也是员工，而是说，人在企业中的身份与分工，必定会导致他们看待问题的角度是不一样的。
换句话说，我们要通过角度的不同，来区分与分隔这些关注点。
正好你给了我们这个概念，那就是我们刚才讲的。现在我们来看下组织结构，有一个方式来描述。此前我们看到的架构师，架构现是一个team的成员。在一个项目组里，当然有些项目比较简单的话，也不需要架构师。当你们架构师项目中有一个架构师的时候，祝你们有一个架构师，这说明你们的系统比较先进了。架构师是一个系统的设置。
17
关于系统的质量问题，要把它分成两部分，一个是开发时的质量，一个是运行时的质量。设计模式这个可能帮你解决了一个重要的quanlity，那就是软件开发的质量。质量本身就包括可扩展性。这个可以通过设计模式的一些原因来表达。
比如下面的这些原则。
(1)、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
(2)、里氏代换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
(3)、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
(4)、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
(5)、迪米特法则（最少知道原则）（Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
(6)、合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。
这些模式都是概念的载体，就是怎么样才能达到我们的可扩展性，例如我们可以通过设计模式来给你一个具体的做法，但前提是，你要了解这些设计模式适用的情景，也就是说你要搞清楚你想要干什么。
18
我们的架构框架，要解决一个首要的问题，就是谁来使用你的软件。
你要找出了你这个系统的涉众找出来。每一个涉众都有很多，所以要进行分割。分割出来的结果就一个关注点。
一个涉众，他的这个不同关注点构成一个集合，不同的集合根据汇总与综合，根据业务的特点，我们把它做成一个模块，然后这些不同模块互相配合，才构成了这样的一个系统。
我们的系统，有不同的涉众，它有不同的是关注点，不同的集合，不同的模块，就相当于每个人都有自己的事业，而涉众就是一个人对应的关注点。
因为人的观点是不一样的，而不同的涉众都有他的利益点，或者说都有他自己的看法，因此不同的涉众，他拥有的关注点就会不同。
我们架构师，通过抽象来分析这些关注点，然后给他取了一个名字就叫涉众。不同的人就需要有不同的设计，然后又对应这个不同的事件，然后这些不同事件又组成了一个完整的整体。
所以我们必须要定义不同事件之间的对应关系，也就是要确定不同的规则、议事，各种人事物，责权利的规则，这都要解决清楚，这我们前进的目标，不然，你也没法进行工作了。
其实，软件相关专业的学生，在他们的课程里，什么项目管理需求分析都学了，但去公司里工作时发现没用，这是因为，全是书本上的，没有实践经验，完全是理论，基本等于没学。
在企业里真正的软件开发，不但有技术因素，还有经济因素，还有政治斗争，我会告诉你这个，不需要解释为什么是这样的，因为没有为什么，是人在干事情，就要靠良心和公平，剩下的是没有什么可以解释了。这叫仁者见仁智者见智。
在刚毕业的学生里喜欢争论理论问题，说你这不符合理论啊，其实吧，你跟我扯没用的意见没意义，你就得接受这个结果，要不你就离开，庙小装不下大神，走人吧。实在是没有办法，因此，我必须弄一个真实的商业系统，在这个基础上，来体现我们的思想路径，以及如何设计。
