1.2 谁是架构师
如你所见，架构通常是关于难以更改的决定。需要有人做出这些决定。
架构设计基于需求分析。分析确定系统要做什么；架构决定如何去做。需要有人了解这个“什么”来确定这个“如何”。
架构师正是把需求和规范关联起来的专家。但架构师的职责是什么？需要哪些技能？
1.2.1 架构师的职责
根据ISO/IEC 42010标准，架构师是负责系统架构的个人、团队或组织。架构师与分析师和项目经理互动，评估和提议系统方案，以及协调开发团队。
架构师参与开发流程的所有阶段，包括需求分析和架构设计、实现、测试、集成以及部署。
具体而言，架构师的主要职责是：确认需求，把系统分解成更小的子系统，识别和评估技术，以及制定规范。
1．确认需求
在软件项目里，有些事情是在架构师参与进来之前发生的。一群分析师、IT经理以及高管见面、讨论、评估以及谈判。一旦确认新增的或者更新系统的需求，而且也有预算，分析师就会引出需求，这通常基于他们对业务、公司流程、环境以及最终用户反馈的了解。
当需求列表准备好时，项目经理通常会与架构师见面，交付一堆东西，然后说：“这是我们（认为我们）想要的，现在你来构建它。”
架构师确认需求，尽力在设计里采用和满足它们。
重要：
刚刚我们提到另一个角色：项目经理。项目经理这个角色在不同公司可能有不同定义。我们认为这个角色负责选定方法学，安排工作，跟踪进度，回报情况，以及充当技术人员和业务人员之间的有效桥梁。充当这个角色的人与充当架构师角色的人可以是同一个人。当这种情况发生 时——而且并不罕见——需求就会从领域专家直接流向开发团队。如果中间有其他人，就会出现领域知识存在误差的风险，就像那个儿童游戏，一个孩子在另一个人的耳朵里小声地说一个词。第二个孩子告诉第3个，如此类推，直到无法猜到原词是什么为止。因此，通过统一语言表达的需求不经过中间渠道或只经过直通渠道（pass-through layer）从领域专家流向开发团队的过程非常关键。
2．分解系统
根据需求，架构师把整个系统描述成在进程里运作的更小的子系统和组件的组合。在这种情况下，架构师构想逻辑层、服务，或者两者都有。然后，根据环境，架构师决定各层的接口，与其他层的关系，以及系统所需的服务级别。
注意：
在这个阶段里，架构师评估各种架构模式。逻辑层是一个常见的选择，也是贯穿本书的一个选择。逻辑层要求垂直分布功能。分区（partitioning）是另一种方案，所有部件都在同一逻辑层次上，分布在一些共享实体（如对象模型或数据库）周围。面向服务架构（SOA）和六角架构（Hexagonal Architecture，HA）等模式倾向于让组件（SOA里的服务，HA里的适配器）在同一逻辑层次上运作和交互。微服务是另一个新近的架构模式，它的核心概念是专门和独立的组件。
整体设计要与企业目标和需求保持一致。特别地，整体设计是由需求驱动，而不是驱动需求。
理论上，产生的架构受到一般原则的启发，比如说，降低组件之间的耦合性，提高组件内部的内聚性，以及赋予每个组件一组清晰的职责。
产生的架构也会受到非功能性需求的驱动，比如说，安全、可伸缩性，以及允许或禁止的技术。所有这些方面都引入了进一步的限制，在一定程度上界定了架构师可以寻找解决方案的范围。
最后，架构师也会制定策略，根据系统的布局把每个组件的开发任务分配给个人开发者或者开发团队。
重要：
软件架构没有绝对真理。没有数学规律（或者建筑工程里的建筑条例）可以帮你做出选择。X公司可能发现A架构很成功，与此同时，Y公司却抛弃了它，采用B架构。事实上，两个都可能完全正确。上下文才是王道，要相信直觉。
3．识别和评估技术
确定需求并设计系统的各层之后，架构师接下来需要把逻辑组件关联到具体的技术和产品。
架构师通常了解可能与项目内容有关的产品和技术的代价和好处。架构师推荐使用的任何技术和产品都是他认为对项目有利和划算的。
架构师没有选择技术，只是根据自身技能提出建议。
架构师可能会建议使用Microsoft SQL Server 2014，因为它的新的聚集列存储索引（clustered column store indexes），或者可能选择由ASP.NET Web API后端支持的单页Web应用程序。类似地，架构师可能会提倡使用本地NoSQL文档存储而不是某种云端表存储。
谁对使用哪些技术和产品做最终决定？
一般是项目经理或者管理预算的人。架构师的建议可能被接受，也可能被拒绝。如果建议被拒绝，那么使用或者不使用某个产品或者技术就会变成一个新的非功能性需求，它甚至可能对架构产生重大影响。
4．制定规范
架构师最终负责系统的开发以及协调开发团队的工作。技术规范是架构师与开发者沟通架构决定的手段。
规范可以有多种形式：UML草图、Microsoft Word文档、Microsoft Visio图表，或者可工作原型。
沟通对架构师来说是非常关键的。沟通会发生在架构师与开发者之间，也会发生在架构师与项目经理和分析师之间，如果不提用户的话。架构师需要具备的一个重要特征是语言清晰。
架构师与开发者之间的互动会因为所选的方法学而有所不同。项目经理、分析师和用户的参与也会因为你所接受的敏捷级别而有所不同。
1.2.2 架构师的角色
架构通常预示了一个被称为“架构师”的角色。根据ISO/IEC，架构师没有不同类型。架构师就是架构师。仅此而已。
但是，如果你环顾周围（以及查看简历），你会看到不少架构师的定义。最终，这是一个被过度使用的词，根据环境、公司，甚至国家，它真的会有非常不同的含义。
1．你知道多少种架构师
在美国，企业架构师（Enterprise Architect，EA）几乎与应用程序开发毫无关系，因为这个角色的人有90%的时间都在关注与IT相关的业务策略、业务编排以及基础设施。简单地说，EA是把业务和IT结合起来的人。这个角色的人选可能对软件架构知之甚少，甚至对分层架构或DDD一无所知。
在很多公司里，负责艰难决定以及建议方案和技术的角色甚至不被称作“架构师”，得到的头衔可能是首席开发者或者类似的名称。
因此，你可以找到企业架构师、基础设施架构师（Infrastructure Architect，IA）、特定技术架构师（Technology-Specific Architect，TSA）以及解决方案架构师（Solution Architect，SA）等称号。所有这些差异都是某种误导，因为它们试图把最终不可分割的复杂角色分解成不同部分。我们认为，它创造了不必要的分类，种下了困惑的祸根——“谁做什么”场景。
在这本书里，我们使用ISO/IEC的架构师定义，即“负责系统架构的个人、团队或者组织”。把这个概念对应到大多数公司就会发现我们所说的架构师是软件（或解决方案）架构师或者首席开发者。
2．架构师的角色
你可能已经有所了解，但如果你去Microsoft TechEd大会，你会发现架构这边几乎没有关于软件开发和架构的现实问题的会议。由于这个原因，我们在过去这些年里提交的大量DDD会议常常被拒绝。除了Microsoft TechEd大会的员工，架构师通常是关注企业架构的角色。而Microsoft TechEd大会上的所有DDD会议都属于开发这边！
在同一个项目组里有多个架构师是没问题的。同样地，不同的架构师拥有稍微不同的技能，即使不是最想要的，也是没问题的。但是，正如我们在本书里强调的，不管官方头衔是什么，架构师与代码有着密切的联系。他们构思系统的设计，然后与开发者密切合作，确保恰当实现。
我们认为，除了其他方面，架构师是一个更好的更有经验的开发者。我们不相信只会使用UML和Visio并把实现细节扔给开发者的架构师是有价值的。至少，当遇到这些人时，我们从未发现他们易于相处。
1.2.3 关于架构师的常见误解
通常，由于架构师这个术语存在各种含义，大量私下的定义和解释也导致了误解的增长。下面来看其中的一些定义，我们也想对它们进行澄清。
1．架构师是分析师
这个说法不实。架构师并不是分析师。
有时候，架构师可能会在捕获需求的过程中协助分析师澄清复杂的需求，或者清除仅为“完整性”而添加进来的千奇百怪的需求。有时候，架构师可能会与利益相关者会面。但也仅此而已。
一般而言，分析师是领域方面的专家。架构师并不一定是这样的专家。分析师会与架构师分享关于系统应该如何工作以及系统应该做什么的发现。
这个常见的误解可能是因为分析师这个词被赋予了不正确的含义。如果这个词只是表明某人对系统做了某些分析，那就很难否定架构师与分析师之间的相似性了。大约30年前，系统分析师这个术语是用来表明在设计系统时做出相关考量的专业能力。但是，那时的软件并不如今天那么重要，只是一个基本上基于硬件的系统的一（小）部分。
今天，分析师与架构师的角色通常被认为是不同的。架构师也很难充当分析师的角色。
注意：
由于角色并不总是严格划分，尤其在小公司里，同一个人可能既是分析师又是架构师。这只是意味着这个公司里有一个人很熟悉业务和流程，可以找出功能性需求，并把它们转化成开发者可以使用的规范。这些角色和职责仍是不同的，只不过这些不同的技能恰好体现在同一个人身上。
2．架构师是项目经理
这是另一个不实的说法吗？看情况而定。
架构师负责系统架构，同时协调和指导系统的开发。项目经理代表利益相关者，通过在一开始选择开发方法学来管理项目。然后，项目经理负责确保项目在时间和预算都有限的情况下开展时能够遵循架构。
如果细看架构师的角色和项目经理的角色，我们会发现它们是不同的。仅此而已。
但是，同一个人最后扮演两个角色也并非罕见。就像演艺界一样，这种事情很少发生在大公司里，但经常发生在小公司里。
总之，如果你以后想成为一名架构师，你不一定要培养项目管理方面的技能。但是，如果你拥有两个角色的技能，你可以尝试拿两份薪水。
3．架构师从不写代码
这绝对是当下热议的问题：架构师应该写代码吗？基本上有两派观点。
一派认为架构师在楼上工作，或许是顶楼。架构师仅在需要通过图表展示他们对系统的看法时才会走下开发者所在的楼层。完事之后，他们乘坐电梯上去，收拾他们的东西，然后出去打高尔夫球了。到了球场，他们会关闭他们的手机，专心打球。打完球时，如果他们发现一两个未接来电，他们会打电话回去，向那些愚笨的开发者解释图表上已经清楚说明但开发者仍然未能理解的东西。根据这一派的观点，架构师从不亲手敲下哪怕最简单的C#语句。C#？噢，不，他们接触过的最新语言，在学校里可能是Pascal，在家里可能是Visual Basic。
相反，另一派认为每个架构师本身都是开发者。把这个比喻推而广之，我们可以说，Architect这个类继承自Developer这个类，添加了一些新的方法（技能），同时又重写了（特化）另一些方法。成为架构师在一些开发者的职业生涯里是很自然的发展。架构师和开发者之间的基本差别是经验和教育。你可以通过工作积累经验，可以通过读好的书和上好的课来获得教育。此外，与普通开发者相比，架构师有能力从更高的层次看待系统。而且，架构师拥有很好的客户应对技能。
架构师可能不写太多产品代码。但他会写很多代码；他每天都实践编码；他了解编程语言、代码技术、库、产品、工具、CTP；他还使用最新的Visual Studio。在某些编程领域，架构师甚至比很多开发者了解得多。架构师可能会写工具帮助开发者提高生产力。更常见的情况是，架构师只是开发团队的一员。比如说，架构师写产品代码在敏捷环境里绝对是正常现象。在小公司里，不管选择哪种开发方法学，这也是正常现象。与此同时，在某些大公司的场景里，让架构师写产品代码可能非常奇怪，尤其是采用了传统的非敏捷的开发方法学。
我们两个呢？我们属于哪一派？
嗯，Andrea比Dino更像架构师，因为他在5楼工作。另外，Dino更像开发者，因为他写过好几本技术含量很高的ASP.NET书，更重要的是，他在二楼工作。但是，我们不打高尔夫球。Dino平时会打网球，而Andrea更喜欢壁球。我们刚被禁止采访第一派的观点。
注意：
“设计的人”和“构建的人”之间的区别在软件领域里很模糊，没有其他工程领域和它一样。这种区别一般是假定的而不是基于公认技能的。
典型的对照物是民用建筑。泥水匠具备工程师没有的独特技能。但是，没有泥水匠会质疑设计和计算，因为他们缺乏独立做出决定的技能。他们尽最大的能力完成自己的工作，完全专注于委派给他们的建筑工作。
在软件领域里，情况有所不同，因为架构师和开发者有着共同的根源。开发者越有能力，就越觉得自己可以讨论设计选择——通常都有理由。架构师对日常编程越是生疏，就越容易失去其他开发者的尊重。这导致了某种程度上的恶性循环，而当你改用敏捷方法学时，情况又会奇迹般地好转。