什么是软件架构？
当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：
’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互
。它有两个非常明显的特点：
关注架构实践的客体——软件，以软件本身作为描述对象。
分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。
‘决策派’认为
软件架构包含了一系列的决策
，主要包括：
软件系统的组织
选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为
用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合
软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
‘决策派’有以下两个显著的特点：
关注软件架构中的实体——人，以人的决策为描述对象。
归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。
按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。《软件架构设计》 温昱
软件中系统架构有哪些啊
如果是软件思想那就是泛指三层架构即B-L-D
软件开发的架构设计指的是什么？
软件架构（software
architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系
统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向
对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw
认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结
构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
但构架不仅是结构；IEEE Working Group
on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注
重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管
理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑
和流程。
一般而言，软件系统的架构（Architecture）有两个要素：
它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心”砖瓦”，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和
联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
软件开发一般比较会关注设计模式而不是架构设计，欢迎追问。
请问软件三层架构是如何架构的,用什么工具开发?
MVC架构模式基于Java的Web应用系统采用MVC架构模式,即model(模型)、view(视图)、control(控制)分离设计.这是目前WEB应用服务系统的主流设计方向.Model:即处理事务逻辑的模块,每一种处理一个模块.View:视图负责页面显示,负责显示MODEL处理结果给用户,主要实现数据到页面转换过程.Control:控制负责每个请求request的分发dispatch,把FORM数据传递给MODEL处理,把处理结果的数据传递给VIEW显示.Eclipse、WebLogic、WebSphere都是基于MVC设计模式的J2EE开发工具
软件架构模式基本概念及三者区别
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。
代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)
一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。称之为系统模式。
•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
•Layers（分层）模式，有时也称Tiers模式
•Blackboard（黑板）模式
•Broker（中介）模式
•Distributed Process（分散过程）模式
•Microkernel（微核）模式
架构模式常常划分成如下的几种：
一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
二、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。
设计模式(Design Pattern)
一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。设计模式在特定的编程语言中实现的时候，常常会用到代码模式。比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。
代码模式(Coding Pattern)
代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等
什么是软件系统架构设计
架构师的职责主要有如下4条：
1、确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
软件设计中的框架和架构的区别
框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。
构架和架构也就是通常所说的软件体系结构(software architecture).体系结构一般包括三个部分:构件,用于描述计算;连接器,用于描述构件的连接部分;配置,将构件和连接器组成一个有机整体.对体系结构比较严谨比较认可的定义可参见＜软件工程技术概论＞（科学出版社）．体系结构与框架（Framework)的区别与联系如下：
1.呈现形式不同．体系结构的呈现形式是一个设计规约，而框架则是程序代码．
2．目的不同．体系结构的首要目的大多是指导一个软件系统的实施与开发；而框架的首要目的是为复用．因此，一个框架可有其体系结构，用于指导该框架的开发，反之不然．
3．有种特殊的体系结构,DSSA(领域特定体系结构）其首要目的也是为了复用．
4.有个叫体系结构风格的东西，将它用程序代码实现后就成了Corba,COM之类的东西，它们俩叫体系结构框架，也叫中间件集成框架，又有人愿意叫它对象中间件
极致软件的技术架构是什么?
极致物业管理系统的技术框架应该是基于极致业务基础平台开发的吧.
怎么区别软件架构，系统架构，解决方案架构，企业架构
不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系，分为以下几种视图：
1. 数据架构：描述数据的存储结构、格式等方面。
2. 物理架构：描述机器的物理部署、网络拓扑方面。
3. 运行架构：描述运行期线程、进程间的交互工作机制。
4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。
5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。
当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。
总的来说，一说到架构，如果你懂软件，那么你会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务。。。但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及他们如何链接在一起。我倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。而采取分离式设计时，最容易的错误就是各自为政，集成困难。那么以数据为中心的架构设计，会自然提供集成的基础。我提到过，企业最重要的资产是数据，甚至不是信息，是数据。企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。这有点象自然演进，考古那种，啥都会消失，唐朝可以无比先进，但都会变，我们唯有找到反映当时情况的数据，才可以把握当思的面貌。
什么是微软技术架构平台?
微软推广的是.NET架构
