软件架构之美，之重要，致使多少人迷失其中。许多盲目追求者，甚至连架构、框架、模式三者之间的关系与区别都分不清，将架构与框架等同的误解现象普遍存在。本人并非功力深厚的大师，却也多多少少在此领域有了自己的体会与感悟，也曾如同大多数人在设计面前迷失，沉沦。只有坚持这个设计，懂得适当放弃过度设计的思想，方能跳出地狱，体会天堂的快乐。本文旨在简要的帮助大家区分架构、框架、模式，与大家共同步入设计

[翻译]架构师应该知道的97件事_04以沟通为中心，兼顾简明清晰的表达方式和开明的领导作风<br /> 04 Communication Is King; Clarity and Leadership, Its Humble Servants<br />以沟通为中心，兼顾简明清晰的表达方式和开明的领导作风<br /><br />Mark Richards<br />马克•理查兹<br /><br />ALL TOO OFTEN, SOFTWARE ARCHITECTS sit in

前言<br />西西弗斯是古希腊神话中的科林斯国王，他被罚将一块巨石推到山上，但无论西西弗斯如何努力，每次石头到达山顶之前都不可避免地滚下来，周而复始，永无休止。<br />在《应用MDA》一书中，作者Frankel将IT人比作现代版的西西弗斯，面对日新月异层出不穷的技术平台，不可避免地不断重复一些工作。理想的MDAer，试图阻止这一悲剧的继续发生。今天，我们通过分析MDA的概念，了解其内涵，看看MDA是否有希望完成这个艰巨的任务。定义<br />MDA是由OMG（Object Management Gro

<br />aid定义 RAID(Redundant Array of Independent Disk 独立冗余磁盘阵列)技术是加州大学伯克利分校1987年 提出，最初是为了组合小的廉价磁盘来代替大的昂贵磁盘，同时希望磁盘失效时不会使对数据的访问受损 失而开发出一定水平的数据保护技术。RAID就是一种由多块廉价磁盘构成的冗余阵列，在操作系统下是作 为一个独立的大型存储设备出现。RAID可以充分发挥出多块硬盘的优势，可以提升硬盘速度，增大容量, 提供容错功能够确保数据安全性，易于管理的优

[翻译]架构师应该知道的97件事_02简化根本复杂性，消除偶发复杂性p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; text-align: justify; font-size: 10.5pt; font-family: "Calibri","sans-serif"; }.MsoChpDefault { font-size: 10pt; }div.Section1 { page: Section1; }02 Simpl

<br />软件可靠性测试的目的<br />软件可靠性测试的主要目的有:<br />(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。<br />(2)为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数<br />据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性<br />估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。<br />(3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。<br

<br />steven_guo 发表于 2005-11-08 00:59:18<br />作者:Jeff Hanson ;steven_guo     来源:javaworld;matrix.org.cn<br />关键字:SOA,Event-driven摘要:这篇文章讨论面向服务框架的技术和机制，这些技术使得该框架高效发送、接受那些跨越层级结构的同步和异步事件，而不需要知道产生这些事件的系统方面的细节. 本文讨论使用Mule实现一个高效的事件驱动和面向服务的平台，一个轻量级的事件-消息架构，企业信息

<br />steven_guo 发表于 2005-11-08 00:59:18<br />作者:Jeff Hanson ;steven_guo     来源:javaworld;matrix.org.cn<br />关键字:SOA,Event-driven摘要:这篇文章讨论面向服务框架的技术和机制，这些技术使得该框架高效发送、接受那些跨越层级结构的同步和异步事件，而不需要知道产生这些事件的系统方面的细节. 本文讨论使用Mule实现一个高效的事件驱动和面向服务的平台，一个轻量级的事件-消息架构，企业信息

<br /> 平台(PanSchema)概述<br />近年来，企业信息化需求旺盛，同时对软件的个性化要求强烈。软件公司往往由于二次开发成本高居不下而难于盈利。软件工程技术在软件复用方面的快速发展，为解决以上市场难题提供了根本出路。这些方法包括：在面向对象基础上发展起来的基于组件的开发（CBD技术）、模型驱动架构（MDA）、面向服务的架构（SOA）及支持SOA的服务组件架构（SCA）、服务数据对象（SDO）等。但是，这些技术的导入很大程度上依赖于工具和平台的支持。“普联应用开发平台PanSc

<br /><br />业务逻辑层简介<br /> <br /> 上图的粗黑色边框的部分就是业务逻辑层，可以包含下面的内容：<br /> 　　application facade应用外观。这个可选的组件为业务逻辑组件提供一个简单的接口，通常会将多个业务操作合并为一个操作，使得业务逻辑层更容易使用。可以减少依赖，因为外部调用者不需要知道业务逻辑组建的实现细节和他们之间的关系。　　业务逻辑组件。在任何应用中，业务逻辑的定义都会集中在获取数据、处理数据、传输数据，管理应用的数据、业务规则和策略，保证数据的

<br />读The Java™ Language Specification（一）——谈异常设计文章分类:Java编程<br />原创文章，转载请保留作者名。 <br /> <br />摘要<br /> <br />Java异常模型的设计是Java应用的架构设计中最重要的决定之一。本文从Java语言规范中第11章对异常的介绍出发，探究Java异常的本质，并介绍Java异常设计的基本原则。<br /> <br />异常的本质<br /> <br />Java语言规范中对于异常的定义如下：<br />当程序违

负载均衡器技术对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。目前有许多不同的负载均衡技术用以满足不同的应用需求，如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡，以及链路聚合技术。 我们使用的是软负载均衡器Nginx,而农行用的是F5硬负载均衡器，这里就简单介绍下这两种技术：l 软件负载均衡

什么是 N层结构<br /> <br />      N层结构（n-tiers结构，多层式运行架构）是相对于两层结构而言的。传统的C/S计算多是基于两级模式，在这种模式中，所有的形式逻辑和业务逻辑均驻留在Client端，而Server则成为数据库服务器，负责各种数据的处理和维护。因此Server变得很“瘦”，被称为“瘦服务器 (Thin Server)”。与之相反，这种模式需要在客户端运行庞大的应用程序，这就是所谓的“胖客户机 (Fat Client)”。<br />  

<br />集群是一个统称，他分为好几种，如高性能科学群集、负载均衡群集、高可用性群集等。 <br />科学群集 <br />通常，这种集群涉及为群集开发并行编程应用程序，以解决复杂的科学问题。它不使用专门的超级并行计算机，而是用商业系统（如通过高速连接来链接的一组单处理器或双处理器PC），并且在公共消息传递层上进行通信以运行并行应用程序。我们常常听说一种便宜的 Linux 超级计算机问世了，大多数情况就是指这种集群系统，其处理能力与真的超级计算机相当，而其价格与上百万美元的专用超级计算机相比是相当的便宜。

软件架构有非常不错的书籍，不过平时也没有时间看，暂且记下:一线架构师实践指南

Scalability Best PracticesHere are a baker’s dozen of items that we feel are Best Practices for Scalability:Asynchronous - Use asynchronous communication when possible. Synchronou

应用架构设计“防火”经验分享Author : 岑文初(淘宝花名：放翁)Email: fangweng@taobao.com Blog: http://blog.youkuaiyun.com/cenwenchu79Date: 2009-08-26          刚从阿软到淘宝不久，

专业架构师，第 1 部分: 开发人员如何成为架构师文档选项<trvalign="top"><img alt="" height="1" width="8"src="//www.ibm.com/i/c.gif"/><img alt="" width=

 SSO（SingleSign-On，单点登录）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。SSO与身份管理软件背景    目前的企业应用环境中，往往有很多的应用系统，如办公自动化（OA）系统，财务管理系统

软件设计中的原则（GRASP） 关键字: GRASP 这里说的几个软件模式是属于原则层次一级的，比GoF等软件设计模式高一层。遵循这些原则可以使我们设计出来的软件有更好的可复用性和可维护性，同样GoF等软件设计模式也是遵循这一原则的。 下边的条列只是简单的介绍，以便忘记

http://zh.wikipedia.org/wiki/%E5%8F%8D%E6%A8%A1%E5%BC%8F 反面模式维基百科，自由的百科全书（重定向自反模式）跳转到： 导航, 搜索在软件工程中，一个反面模式（anti-pattern或antipattern）指的是在实践中明显出现但又低效或是有待优化的设计模式[1][

数据库设计规范与技巧一、数据库设计过程　　数据库技术是信息资源管理最有效的手段。　　数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。　　数据库设计的各阶段：

1.设计原则 （1）用户原则。人机界面设计首先要确立用户类型。划分类型可以从不同的角度，视实际情况而定。确定类型后要针对其特点预测他们对不同界面的反应。这就要从多方面设计分析。（2）信息最小量原则。人机界面设计要尽量减少用户记忆负担，采用有助于记忆的设计方案。（3）帮助和提示原则。要对用户的操作命令作出反应，帮助用户处理问题。系统要设计有恢复出错现场的能力，在系统内

数据表的设计原则 (1)不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 (2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首

<br />近来有好几篇文章，主题都是关于SOA是否应当被看作是一个失败。Gartner分析师们也参与了这场争论，写了一封虚拟的信，以项目经理、企业架构师或首席开发工程师的名义，致“CIO、CEO、CFO、CTO和所有股东”，表明为什么作者承认SOA完全是场失败：<br />　　作为下述情况的结果，我只能得出SOA是场失败，对于SOA的任何尝试都会以失败收场。在我的领导下：<br />　　尽管下列失败的原由都是以调侃的口吻来叙述的，但它们却与人们在考虑SOA时所识别出的可能的失败原由息息相关

<br />ADMEMS 好像是一个不错的架构设计方法，这里先贴上宣传页面，改天有时间的时候做研究<br /> <br />方法体系作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。其中“3个阶段”是指预备架构阶段（PA阶段）、概念架构阶段（CA阶段）、细化架构阶段（RA阶段），“1个贯穿环节”是指对非功能目标的考虑。<br /><br />PA阶段的任务是全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心；C

《如何将系统模块化》一文阐述了系统模块化的重要性，应遵守的高内聚低耦合的原则，以及常用大粒度的划分方法,并对一些原则进行了相应的补充说明。当然要编写出高质量的软件程序，还需要理清需求，把控好设计，使用恰当的技术，处理好业务逻辑，编写高质量的代码，更需要一遍又一遍的重构改进