酱油爆鱼
什么是软件架构？
当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：'组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。
它有两个非常明显的特点：关注架构实践的客体——软件，以软件本身作为描述对象。
分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。
'决策派'认为软件架构包含了一系列的决策，主要包括：软件系统的组织选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
'决策派'有以下两个显著的特点：关注软件架构中的实体——人，以人的决策为描述对象。
归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。
按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。
我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。
《软件架构设计》 温昱
什么是系统架构设计？
展开全部 不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系，分为以下几种视图： 1. 数据架构：描述数据的存储结构、格式等方面。
2. 物理架构：描述机器的物理部署、网络拓扑方面。
3. 运行架构：描述运行期线程、进程间的交互工作机制。
4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。
5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。
例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。
当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。
就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。
当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。
总的来说，一说到架构，如果懂软件，那么会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务……但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及如何链接在一起。
倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时，最容易的错误就是各自为政，集成困难。
那么以数据为中心的架构设计，会自然提供集成的基础。
提到过，企业最重要的资产是数据，甚至不是信息，是数据。
企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。
这有点象自然演进，考古那种，啥都...
什么是分布式系统,如何学习分布式系统
有一些系统设计基础的话，给你推荐几本书吧：《面向模式的软件架构 卷4：分布式计算的模式语言》出版社：人民邮电出版社主要讲分布式计算系统软件的设计和实现。
偏软件方向，相对较专业。
《分布式计算（第二版）》出版社：电子工业出版社主要介绍分布式计算的数学基础和理论，揭示设计分布式系统的底层问题（通信、协调、同步及不确定）和基本的算法概念及下界技术。
容易理解，适合自学。
《分布式系统原理与范型》出版社：清华大学出版社全书的第一部分讨论了分布式系统的原理、概念和技术，其中包括通信、进程、命名、同步、一致性和复制、容错以及安全。
第二部分给出了一些实际的分布式系统：基于对象的分布式系统、分布式文件系统、基于文档的分布式系统以及基于协作的分布式系统，介绍了一些实际系统的设计思想和实现技术。
容易理解，适合自学。
编写软件架构文档说明,第 1 部分： 什么是软件架构,为什么为软件...
引言 软件架构是一门学科，开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。
与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。
在本系列中，您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的；每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关，并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别，存在一些混淆。
正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 （C1）。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。
对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。
作为一门学科，软件架构是非常成熟的。
您可以利用最佳实践和指导...
软件构架有什么作用？
《.NET软件架构之美（英文版）》出自两位具有多年软件开发经验的 ASP .NET专家、作者和培训师之手，内容涉及多层架构、设计模式以及设计原则。
第一部分简要介绍 UML、设计原则及模式；第二部分从技术架构角度讨论分层设计。
《.NET软件架构之美（英文版）》行文流畅，语言通俗易懂，阐述了各种架构设计技术方案的优与劣，并讲述了如何在优与劣中做出权衡。
中设计了真实的场景，展示了如何将这些设计原则更加具体地应用到 .NET应用程序中。
如何学习分布式系统
架构师的职责主要有如下4条：1、确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。
架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。
随后，架构师会确定各层的接口，层与层相互之间的关系。
架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。
技术选择主要取决于软件架构。
WebServer运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。
架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明架构师在项目开发过程中，是技术权威。
他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。
所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
java入门书籍推荐
展开全部 我推荐几本书吧 希望你按照顺序看 先看《head first java》（有中文版，下面2本书都是有中文版的）很浅显易懂而且图文并茂，用对话的方式讲解，你不会感到疲惫，能让你快速上手。
【肯定很权威，sun认证考试是他们出题的】再看第二本《java核心技术卷1-基础知识》，bruce eckel推荐的入门书籍。
第三本是《java核心技术卷2-高级特性》。
第四本是bruce eckel本人编写的《java编程思想》。
第五本是《head first servlet &jsp》。
第六本是《head first ejb》。
后面的关于web开发，现在流行使用框架技术，本人认为没有较好的书籍---但有个出路（直接到官方网站看api文档和示例程序源码）。
...
