软件架构模式基本概念及三者区别：
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。
代码模式是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)
一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。称之为系统模式。
•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式常常包括调停者模式、策略模式、合成模式、观察者模式等。
•Layers模式，有时也称Tiers模式
•Blackboard模式
•Broker模式
•Distributed Process模式
•Microkernel模式
架构模式常常划分成如下的几种：
一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。包括Layers模式、Blackboard模式、Pipes/Filters模式等。
二、分散系统型。为分散式系统提供完整的架构设计，包括像Broker模式等。
三、人机互动型，支持包含有人机互动介面的系统的架构设计，例子包括MVC模式、PAC模式等。
四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection模式、Microkernel模式等。
设计模式(Design Pattern)
一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
创建型设计模式，如工厂方法模式、抽象工厂模式、原型模式、单例模式，建造模式等
结构型设计模式，如合成模式、装饰模式、代理模式、享元模式、门面模式、桥梁模式等
行为型模式，如模版方法模式、观察者模式、迭代子模式、责任链模式、备忘录模式、命令模式、状态模式、访问者模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。设计模式在特定的编程语言中实现的时候，常常会用到代码模式。比如单例模式的实现常常涉及到双检锁模式等。
代码模式(Coding Pattern)
代码模式是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁模式等
组织架构有几种模式?：
组织架构自从被提出以来，很多企业中都采用了不同的模式的，一般分为四种模式：
1、直线型，上下级的关系贯穿最高层到最底层，属于指挥形式的组织结构。
2、职能型，企业根据职能的不同分为多种不同的部门，权力是比较集中的，企业控制简单。
3、矩阵型，虽然多用于项目管理，但是对于一些技术复杂的企业使用也是很广泛的，便于发挥不同人才的能力。
4、事业部型，这是按照不同产品、不同地区划分的企业组织机构，实用性还是很高的，适合多元化的管理。
架构图
组织结构图是组织架构的直观反映，是最常见的表现雇员、职称和群体关系的一种图表，它形象地反映了组织内各机构、岗位上下左右相互之间的关系。
组织架构图是从上至下、可自动增加垂直方向层次的组织单元、图标列表形式展现的架构图，以图形形式直观的表现了组织单元之间的相互关联，并可通过组织架构图直接查看组织单元的详细信息，还可以查看与组织架构关联的职位、人员信息。
架构模式有哪些：
架构模式 这，从俗语言说一下吧：层。模型-视图-控制。表示-抽象-控制等
1.三层架构
2.单例模式，工厂模式等
3.分层架构模式
架构的构架模式：
构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。
根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 【BUS96】 中所提供的类别和这些类别所包含的模式。 类别 模式 结构 层 管道和过滤器 黑板 分布式系统 代理 交互系统 模型-视图-控制器 表示-抽象-控制 自适应系统 反射 微核 为阐明其含义，下面将详述其中的两个。完整说明请参见 【BUS96】。
模式以下列广泛使用的形式来表示：模式名、环境、问题、影响，描述应考虑的不同问题方面、解决方案、基本原理、结果环境、示例、模式名层、环境、需要进行结构分解的大系统、问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题。
影响：系统的某些部分应当是可替换的；构件中的变化不应波动；相似的责任应归为一组；构件大小 -- 复杂构件可能要进行分解
解决办法：将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层提供的服务。尽量不使用非紧邻下层提供的服务。
示例：
1. 通用层
严格的分层构架规定设计元素只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。
2. 业务系统层
右图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。
环境：没有解决问题的确定方法或方法不可行的领域。例如 AI 系统、语音识别和监视系统。
问题：多个问题解决顾问必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。
影响：知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略；不同顾问的输入可能有不同的表示方式；各顾问并不直接知道对方的存在，但可以评估对方发布的工作
解决办法：多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分解决方案放置于黑板上。
示例：
以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。
构架风格
软件构架可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南中。样式在构架的可理解性与完整性方面起着主要的作用。
欢迎分享，转载请注明来源：民族网
