如何带领团队“攻城略地”？优秀的架构师这样做
架构师是一个既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后，是艰辛的探索。
架构师职责
架构师不是一个人，他需要建立高效卓越的体系，带领团队去攻城略地，在规定的时间内完成项目。
架构师需要能够识别定义并确认需求，能够进行系统分解形成整体架构，能够正确地技术选型，能够制定技术规格说明并有效推动实施落地。
按 TOGAF 的定义，架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，架构师的角色有：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。
从业界来看对于架构师的理解可以大概区分为：
- 企业架构师：专注于企业总体 IT 架构的设计。
- IT 架构师-软件产品架构师：专注于软件产品的研发。
- IT 架构师-应用架构师：专注于结合企业需求，定制化 IT 解决方案；大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。
- IT 架构师-技术架构师：专注于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。
架构思维
自顶向下构建架构
要点主要如下：
1.首先定义问题，而定义问题中最重要的是定义客户的问题。定义问题，特别是识别出关键问题，关键问题是对客户有体感，能够解决客户痛点，通过一定的数据化来衡量识别出来，关键问题要优先给出解决方案。
2.问题定义务必加入时间维度，把手段/方案和问题定义区分开来。
3.问题定义中，需要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，理清和挖掘清楚需求；要善用第一性原理思维进行分析思考问题。
4.问题解决原则：先解决客户的问题（使命），然后才能解决自己的问题（愿景）；务必记住不是强调我们怎么样，而是我们能为客户具体解决什么问题，然后才是我们变成什么，从而怎么样去更好得服务客户。
5.将抽象出来的能力诉求转换成技术挑战，此步对于技术人员来说相当于找到了靶子，可以进行方案的设计了，需要结合自底向上的架构推导方式。
6.创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新，升层思考、升维思考，使用第一性原理思维、生物学（进化论--进化=变异+选择+隔离、熵增定律、分形和涌现）思维等哲科思维可以帮助我们在业务，产品，技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。
自底向上推导应用架构
先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块，模块的组合／聚合构建整个系统架构。
基本上应用逻辑架构的推导有4个子路径，他们分别是：
- 业务概念架构：业务概念架构来自于业务概念模型和业务流程；
- 系统模型：来自于业务概念模型；
- 系统流程：来自业务流程；
- 非功能性的系统支撑：来自对性能、稳定性、成本的需要。
效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素，所以从逻辑架构到物理架构，一定需要先对效率、稳定性和性能做出明确的量化要求。
领域驱动设计架构
大部分传统架构都是基于领域模型分析架构，典型的领域实现模型设计可以参考DDD（领域驱动设计），详细可以参考《实现领域驱动设计》这本书，另外《UML和模式应用》在领域建模实操方面比较好，前者偏理论了解，后者便于落地实践。
基于数据驱动设计架构
随着 IoT、大数据和人工智能的发展，以领域驱动的方式进行架构往往满足不了需求或者达不到预期的效果，在大数据时代，在大数据应用场景，我们需要转变思维，从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里需要架构师具备数理统计分析的基础和 BI 的能力，以数据思维来架构系统，典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。
上述四种思维，往往在架构设计中是融合使用的，需要根据业务或者系统的需求来选择侧重思维方式。
架构原则
设计原则就是架构设计的指导思想，它指导我们如何将数据和函数组织成类，如何将类链接起来成为组件和程序。反向来说，架构的主要工作就是将软件拆解为组件，设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。
设计原则有很多，我们进行架构设计的主导原则是 OCP（开闭原则），在类和代码的层级上有：SRP（单一职责原则）、LSP（里氏替换原则）、ISP（接口隔离原则）、DIP（依赖反转原则）；在组件的层级上有：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则。
如何面向失败设计
作为一个悲观主义者，你需要在一开始的系统设计阶段就考虑到以上各种失败场景，把面向失败当成系统设计的一部分，并且准备好从失败中恢复的策略，这有助于更好地提升整个系统的可用性。只有你意识到事情会随着时间的推移而失败，并将这种思想融入到体系结构中，那么在失败发生的时候你才能完全不受影响或者将失败损失降到最低。面向失败的设计理念数十年来并没有多大的变化，一些好的经典原则在今天依旧被广泛运用。
