首席架构师汪洋坐镇，欢迎大伙提问啊：软件架构连载讨论之一：正确认识软件架构

yanyangtian4502

看了,不过还是没有回答我的问题.我目前的公司,不需要我们做什么设计,因为框架定了,我们只写actio ...
fxbird 发表于 2011-10-24 16:54

    我的机会也是自己争取到的：平时在项目中，高质量的完成任务，信任建立起来之后，慢慢的有了机会。并且自己平时也是做些自己的东西，锻炼和验证自己的想法！

fxbird

我的机会也是自己争取到的：平时在项目中，高质量的完成任务，信任建立起来之后，慢慢的有了机会 ...
yanyangtian4502 发表于 2011-10-24 22:54

嗯,目前我有两个想法,一是模仿公司的框架自己写一个,当然有些功能不必加进去.练练手,二是看看那些招架构师的公司招不招普通开发人员,架构师可能不会招没有经验的,但如果以开发人员身份进去,慢慢努力,相信会有机会.可能也就这两条路了吧,我也不认识这样公司的牛人,否则,还可以介绍一下.

xdsnet

架构从广义来说是一种独立于软件实现设计的另外一种设计或者说另外一个层次的设计。
      前面朋友用沙模来类比架构与软件实现项目的关系我觉得很恰当，而且抽象出架构是架构的作用是明确最终产品的目的以及相应的约束，这点很关键。

      我觉得的 架构/软件设计/编码实现 是逐渐推进的过程，从大的流程来说，架构/软件设计 都是设计的范畴。

      前面还有朋友提到 架构的基础是业务的识别，我觉得这也很关键，但需要指出的是架构与需求挖掘还是有本质的不同，需求挖掘仅仅停留在识别需求上，架构应该在识别基础上有一个再次整合优化的过程，因为很多
业务实施信息化的过程中不能照搬以往经验，必须要对流程进行梳理，要去除大量的干扰并优化以合适信息化实施。所以架构师可能需要对业务有深入认识，还要有在专业人员帮助下（或者有类似专业知识）进行信息化
处理优化。

yulihua49

我的理解应用架构就是指Midware（中间层）。
应用层架构是否包括以下几方面：
1. GUI框架
2. 窗体框架
...
白村人 发表于 2011-10-13 14:20

    不是。它们应该是架构师的素材，不止这些，还有很丰富的内容。

yulihua49

高并发的问题很复杂，解决起来很棘手，既要考虑数据的正确性与完整性，同时又要考虑系统性能。不 ...
snow888 发表于 2011-10-13 11:26

这是架构师需要重点考虑的因素，他用什么素材来对付这个挑战，就是架构师的水平。

架构这个词可意会不可言传，听听如何定义之。不过一个架构师的职责应该是明确的。

bbjmmj

    其实架构可以说是“平台无关性，也不涉及到具体的技术细节”。
yanyangtian4502 发表于 2011-10-13 00:12

    架构就是体系结构吧？怎么能跟平台无关呢？

yanyangtian4502

总结帖1：

什么是架构

首先，让我们来看看架构的一个定义：

软件架构是对系统的高层视角，或者是对系统的抽象。它关注的是某些对完成这个系统有着最大帮助的方面，例如：可用性、稳定性，以及灵活性。同时，架构对如何达到这些目的给出了指导和约束。

如果要用最简单的方式来理解上面的定义，可以这样说：软件架构就是软件系统的一张蓝图。

下面我们用一个比较浅显的类比来说明这个“蓝图”的含义。
相信大家对冶金行业中的“浇筑”或多或少有一些了解。浇筑就是把液体材料倒在一个有着特定形状的沙模中，然后等液体冷却之后得到想要的产品或特定形状材料的过程。在这个过程中，盛放液体的沙模引导着液体慢慢成形，最后得到我们预想的结果。

其中，有一点要注意的是，沙模的特性（比如形状和大小）和倒入其中的液体是没有任何联系的，换句话说：沙模和液体是完全分离的，但是沙模又必须和液体在一起才能生产出所要的产品。

架构就好比上面例子中的沙模，软件项目就好比用于浇筑的液体。正如浇筑一样，架构引导着项目，最后得到了我们想要的结果。同时，我们也可以得出：软件的架构和实现这个系统的代码是没有很严格的关系的，这也就是我们常说的架构是平台无关的。架构可确保开发的过程在一定的限制或规则下进行。

对于沙模来说，如果没有浇筑液体的存在，它基本就没有任何作用；架构也是立足项目的特定需求来设计的！

yanyangtian4502

总结帖2：

架构师的职责

既然已经了解架构的含义，那我们再来看看负责创建架构的责任人：架构师。

架构师这个角色在任何软件开发项目中都是最有挑战性的。

1. 架构师的领导与决策能力

首先，架构师是一位技术领导，这意味着架构师除了拥有专门的技能外，还必须拥有领导能力，领导能力也要能体现在组织中的职位上。

从职位上来讲，架构师是项目中的技术领导，应该拥有进行技术决策的权威。不过，很多时候架构师和项目经理的职责很容易让人混淆，下面用电影行业的职位来打一个比方，帮助大家了解他们的不同：项目经理是制片人（确保事情完成），而架构师是导演（确保事情正确地完成）。架构师和项目经理代表了这个项目的公共角色，对于项目外的关注人员来说，他们是主要的联系点。架构师尤其应该是创建一个架构及给组织带来价值的投资倡导者
。
在决策方面，架构师要综合考虑，果断下决定。例如，在某些情况不清楚或没有充足的时间探究所有的可能性及有交付压力的情况下，如果架构师不能进行决策，那是不行的。而且这样的环境会很常见，架构师要接受这个现实而不是设法改变它。

有些时候，架构师会在决策时咨询其他人并营造其他人共同参与决策的环境，但是进行适当的决策仍然是架构师的职责，即使有时候这些决策并不总是正确的（当然，是事后才发现这些决策不正确的）。因此，架构师必须是厚脸皮的，因为他们可能必须纠正他们的决策并原路返回。

没有决策能力的架构师会使项目慢慢被破坏。项目团队会对架构师失去信心，项目经理将会担心，因为这些等待架构师决策的事项没有进展。更加危险的是：如果架构师没有制定关于架构的决策并编写成文档，团队成员会开始制定他们自己的（可能是不正确的）决策。

2. 架构师的角色可能由一个团队来履行

角色和人之间是存在差异的。一个人可能会履行很多个角色，一个角色也可能会由许多人来履行。由于架构师需要非常广泛的技能，所以，架构师这个角色可能会由多个人来履行，这时，架构团队中的每个人都可以充分运用他自己的经验来履行此角色。特别是在理解业务领域和各方面技术所必需的技能时，往往需要多人合作才能达到相关要求。有一点很重要，就是最终的团队必须平衡。

如果架构师角色由一个团队来履行，拥有一个首席架构师就非常重要了，他是架构团队的协调人，经常会有先见之明。没有这个协调人，要让架构团队的成员创造出内聚的架构，或做出决策是很困难的。

对于一个不熟悉架构概念的团队来说，为了达成共同的目的，建议团队应该创建并颁布一个团队规章。
优秀的架构师知道他们的优势和弱势。最优秀的架构通常由一个团队而不是个人创建的，这都是因为“众人力量大”，人多则见识更广和更深。


3. 架构师要理解软件开发流程
大部分架构师曾经都做过开发人员（几乎是绝大部分架构师都是从开发人员走过来的），同时，架构师应该了解软件开发流程，因为这个流程能确保团队的所有成员协调的工作。

这种协调性可以通过定义涉及的角色、从事的任务、创建的工作产品、不同角色之间的移交点来获得。因为在日常工作中架构师会影响许多团队成员，所以理解团队成员的角色和职责，理解他们正在生产和使用的东西对于架构师来说很重要。实际上，团队成员也非常希望架构师能够指导他们的工作。

4. 架构师掌握技术与设计知识

架构设计会涉及技术知识，所以，一个架构师应该拥有一定程度的技术技能。不过，架构师不必是一个技术专家，他要关注的是技术相关重要因素，而不是细节（其实很多时候，架构师也是技术专家，而且对细节理解得非常深入）。架构师需要理解像Java EE或.NET这样的平台上可用的关键框架，但是不必理解这些平台程序编程接口（API）的细节。

架构师必须与项目中的开发人员打交道，只有当架构师承认开发人员的工作价值时，在架构师和开发人员之间的沟通才是有效的。这也说明了，架构师应该具有一定的编程技能，即使他们在项目中不必编写代码，也必须跟上技术更新的脚步。

架构师应该有组织地参与开发，并且尽可能地参与代码的编写。如果架构师参与实现，开发团队会从架构师那儿获得见识。架构师还可以通过查看他们决策和设计的第一手结果来进行学习，从而对开发流程给出反馈。

大部分成功的软件架构师都曾经是核心的编程人员。某种程度上来说，他们就是通过这段经历了解到业务的某些情况的。如果没有这些知识，要实架构上的重要元素（如源代码的组织、采用的编程标准）时，架构师将无法进行决策，架构师和开发人员之间将会存在沟通障碍。

另外，设计是架构设计的核心。架构使关键设计决策具体化，因此，架构师应该拥有很强的设计技能。关键设计决策指的是关键结构的设计决策、特定模型的选择、指导规格说明书等。

一个人不可能在短时间内获得设计能力，这是多年经验累积的结果。某些设计专家在回顾他们早期的工作时都会惊讶他们原来的设计是如此的不好。在学习一项新技能时，想要对此精通则必须进行设计实践。

yanyangtian4502

总结帖2：

架构师的职责

既然已经了解架构的含义，那我们再来看看负责创建架构的责任人：架构师。

架构师这个角色在任何软件开发项目中都是最有挑战性的。

1. 架构师的领导与决策能力

首先，架构师是一位技术领导，这意味着架构师除了拥有专门的技能外，还必须拥有领导能力，领导能力也要能体现在组织中的职位上。

从职位上来讲，架构师是项目中的技术领导，应该拥有进行技术决策的权威。不过，很多时候架构师和项目经理的职责很容易让人混淆，下面用电影行业的职位来打一个比方，帮助大家了解他们的不同：项目经理是制片人（确保事情完成），而架构师是导演（确保事情正确地完成）。架构师和项目经理代表了这个项目的公共角色，对于项目外的关注人员来说，他们是主要的联系点。架构师尤其应该是创建一个架构及给组织带来价值的投资倡导者
。
在决策方面，架构师要综合考虑，果断下决定。例如，在某些情况不清楚或没有充足的时间探究所有的可能性及有交付压力的情况下，如果架构师不能进行决策，那是不行的。而且这样的环境会很常见，架构师要接受这个现实而不是设法改变它。

有些时候，架构师会在决策时咨询其他人并营造其他人共同参与决策的环境，但是进行适当的决策仍然是架构师的职责，即使有时候这些决策并不总是正确的（当然，是事后才发现这些决策不正确的）。因此，架构师必须是厚脸皮的，因为他们可能必须纠正他们的决策并原路返回。

没有决策能力的架构师会使项目慢慢被破坏。项目团队会对架构师失去信心，项目经理将会担心，因为这些等待架构师决策的事项没有进展。更加危险的是：如果架构师没有制定关于架构的决策并编写成文档，团队成员会开始制定他们自己的（可能是不正确的）决策。

2. 架构师的角色可能由一个团队来履行

角色和人之间是存在差异的。一个人可能会履行很多个角色，一个角色也可能会由许多人来履行。由于架构师需要非常广泛的技能，所以，架构师这个角色可能会由多个人来履行，这时，架构团队中的每个人都可以充分运用他自己的经验来履行此角色。特别是在理解业务领域和各方面技术所必需的技能时，往往需要多人合作才能达到相关要求。有一点很重要，就是最终的团队必须平衡。

如果架构师角色由一个团队来履行，拥有一个首席架构师就非常重要了，他是架构团队的协调人，经常会有先见之明。没有这个协调人，要让架构团队的成员创造出内聚的架构，或做出决策是很困难的。

对于一个不熟悉架构概念的团队来说，为了达成共同的目的，建议团队应该创建并颁布一个团队规章。
优秀的架构师知道他们的优势和弱势。最优秀的架构通常由一个团队而不是个人创建的，这都是因为“众人力量大”，人多则见识更广和更深。


3. 架构师要理解软件开发流程

大部分架构师曾经都做过开发人员（几乎是绝大部分架构师都是从开发人员走过来的），同时，架构师应该了解软件开发流程，因为这个流程能确保团队的所有成员协调的工作。

这种协调性可以通过定义涉及的角色、从事的任务、创建的工作产品、不同角色之间的移交点来获得。因为在日常工作中架构师会影响许多团队成员，所以理解团队成员的角色和职责，理解他们正在生产和使用的东西对于架构师来说很重要。实际上，团队成员也非常希望架构师能够指导他们的工作。

4. 架构师掌握技术与设计知识

架构设计会涉及技术知识，所以，一个架构师应该拥有一定程度的技术技能。不过，架构师不必是一个技术专家，他要关注的是技术相关重要因素，而不是细节（其实很多时候，架构师也是技术专家，而且对细节理解得非常深入）。架构师需要理解像Java EE或.NET这样的平台上可用的关键框架，但是不必理解这些平台程序编程接口（API）的细节。

架构师必须与项目中的开发人员打交道，只有当架构师承认开发人员的工作价值时，在架构师和开发人员之间的沟通才是有效的。这也说明了，架构师应该具有一定的编程技能，即使他们在项目中不必编写代码，也必须跟上技术更新的脚步。

架构师应该有组织地参与开发，并且尽可能地参与代码的编写。如果架构师参与实现，开发团队会从架构师那儿获得见识。架构师还可以通过查看他们决策和设计的第一手结果来进行学习，从而对开发流程给出反馈。

大部分成功的软件架构师都曾经是核心的编程人员。某种程度上来说，他们就是通过这段经历了解到业务的某些情况的。如果没有这些知识，要实架构上的重要元素（如源代码的组织、采用的编程标准）时，架构师将无法进行决策，架构师和开发人员之间将会存在沟通障碍。

另外，设计是架构设计的核心。架构使关键设计决策具体化，因此，架构师应该拥有很强的设计技能。关键设计决策指的是关键结构的设计决策、特定模型的选择、指导规格说明书等。

一个人不可能在短时间内获得设计能力，这是多年经验累积的结果。某些设计专家在回顾他们早期的工作时都会惊讶他们原来的设计是如此的不好。在学习一项新技能时，想要对此精通则必须进行设计实践。

yanyangtian4502

总结帖2：

架构师的职责

既然已经了解架构的含义，那我们再来看看负责创建架构的责任人：架构师。

架构师这个角色在任何软件开发项目中都是最有挑战性的。

1. 架构师的领导与决策能力

首先，架构师是一位技术领导，这意味着架构师除了拥有专门的技能外，还必须拥有领导能力，领导能力也要能体现在组织中的职位上。

从职位上来讲，架构师是项目中的技术领导，应该拥有进行技术决策的权威。不过，很多时候架构师和项目经理的职责很容易让人混淆，下面用电影行业的职位来打一个比方，帮助大家了解他们的不同：项目经理是制片人（确保事情完成），而架构师是导演（确保事情正确地完成）。架构师和项目经理代表了这个项目的公共角色，对于项目外的关注人员来说，他们是主要的联系点。架构师尤其应该是创建一个架构及给组织带来价值的投资倡导者
。
在决策方面，架构师要综合考虑，果断下决定。例如，在某些情况不清楚或没有充足的时间探究所有的可能性及有交付压力的情况下，如果架构师不能进行决策，那是不行的。而且这样的环境会很常见，架构师要接受这个现实而不是设法改变它。

有些时候，架构师会在决策时咨询其他人并营造其他人共同参与决策的环境，但是进行适当的决策仍然是架构师的职责，即使有时候这些决策并不总是正确的（当然，是事后才发现这些决策不正确的）。因此，架构师必须是厚脸皮的，因为他们可能必须纠正他们的决策并原路返回。

没有决策能力的架构师会使项目慢慢被破坏。项目团队会对架构师失去信心，项目经理将会担心，因为这些等待架构师决策的事项没有进展。更加危险的是：如果架构师没有制定关于架构的决策并编写成文档，团队成员会开始制定他们自己的（可能是不正确的）决策。

2. 架构师的角色可能由一个团队来履行

角色和人之间是存在差异的。一个人可能会履行很多个角色，一个角色也可能会由许多人来履行。由于架构师需要非常广泛的技能，所以，架构师这个角色可能会由多个人来履行，这时，架构团队中的每个人都可以充分运用他自己的经验来履行此角色。特别是在理解业务领域和各方面技术所必需的技能时，往往需要多人合作才能达到相关要求。有一点很重要，就是最终的团队必须平衡。

如果架构师角色由一个团队来履行，拥有一个首席架构师就非常重要了，他是架构团队的协调人，经常会有先见之明。没有这个协调人，要让架构团队的成员创造出内聚的架构，或做出决策是很困难的。

对于一个不熟悉架构概念的团队来说，为了达成共同的目的，建议团队应该创建并颁布一个团队规章。
优秀的架构师知道他们的优势和弱势。最优秀的架构通常由一个团队而不是个人创建的，这都是因为“众人力量大”，人多则见识更广和更深。


3. 架构师要理解软件开发流程

大部分架构师曾经都做过开发人员（几乎是绝大部分架构师都是从开发人员走过来的），同时，架构师应该了解软件开发流程，因为这个流程能确保团队的所有成员协调的工作。

这种协调性可以通过定义涉及的角色、从事的任务、创建的工作产品、不同角色之间的移交点来获得。因为在日常工作中架构师会影响许多团队成员，所以理解团队成员的角色和职责，理解他们正在生产和使用的东西对于架构师来说很重要。实际上，团队成员也非常希望架构师能够指导他们的工作。

4. 架构师掌握技术与设计知识

架构设计会涉及技术知识，所以，一个架构师应该拥有一定程度的技术技能。不过，架构师不必是一个技术专家，他要关注的是技术相关重要因素，而不是细节（其实很多时候，架构师也是技术专家，而且对细节理解得非常深入）。架构师需要理解像Java EE或.NET这样的平台上可用的关键框架，但是不必理解这些平台程序编程接口（API）的细节。

架构师必须与项目中的开发人员打交道，只有当架构师承认开发人员的工作价值时，在架构师和开发人员之间的沟通才是有效的。这也说明了，架构师应该具有一定的编程技能，即使他们在项目中不必编写代码，也必须跟上技术更新的脚步。

架构师应该有组织地参与开发，并且尽可能地参与代码的编写。如果架构师参与实现，开发团队会从架构师那儿获得见识。架构师还可以通过查看他们决策和设计的第一手结果来进行学习，从而对开发流程给出反馈。

大部分成功的软件架构师都曾经是核心的编程人员。某种程度上来说，他们就是通过这段经历了解到业务的某些情况的。如果没有这些知识，要实架构上的重要元素（如源代码的组织、采用的编程标准）时，架构师将无法进行决策，架构师和开发人员之间将会存在沟通障碍。

另外，设计是架构设计的核心。架构使关键设计决策具体化，因此，架构师应该拥有很强的设计技能。关键设计决策指的是关键结构的设计决策、特定模型的选择、指导规格说明书等。

一个人不可能在短时间内获得设计能力，这是多年经验累积的结果。某些设计专家在回顾他们早期的工作时都会惊讶他们原来的设计是如此的不好。在学习一项新技能时，想要对此精通则必须进行设计实践。