1. 架构思维
1.1. 抽象思维
在系统架构和设计中，抽象帮助我们从大处着眼（get our mind about big picture），隐藏细节（temporarily hide details）。抽象能力的强弱，直接决定我们所能解决问题的复杂性和规模大小。
1.2. 分层思维
除了抽象，分层也是我们应对和管理复杂性的基本思维武器，为了构建一套复杂系统，我们把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。有些层次是纵向的，它贯穿所有其它层次，称为共享层。分层也可以认为是抽象的一种方式，将系统抽象分解成若干层次化的模块。
1.3. 分治思维
分而治之(divide and combine或者split and merge)也是应对和管理复杂性的一般性方法。
对于一个无法一次解决的大问题，我们会先把大问题分解成若干个子问题，如果子问题还无法直接解决，则继续分解成子子问题，直到可以直接解决的程度，这个是分解(divide)的过程；然后将子子问题的解组合拼装成子问题的解，再将子问题的解组合拼装成原问题的解，这个是组合(combine)的过程。
1.4. 演化思维
社区里头经常有人在讨论：架构是设计出来的？还是演化出来的？我个人基于十多年的经验认为，架构既是设计出来的，同时也是演化出来的，对于互联网系统，基本上可以说是三分设计，七分演化，而且是在设计中演化，在演化中设计，一个不断迭代的过程。
在互联网软件系统的整个生命周期过程中，前期的设计和开发大致只占三分，在后面的七分时间里，架构师需要根据用户的反馈对架构进行不断的调整。我认为架构师除了要利用自身的架构设计能力，同时也要学会借助用户反馈和进化的力量，推动架构的持续演进，这个就是演化式架构思维。
当然一开始的架构设计非常重要，架构定系统基本就成型了，不容马虎。同时，优秀的架构师深知，能够不断应对环境变化的系统，才是有生命力的系统，架构的好坏，很大部分取决于它应对变化的灵活性。所以具有演化式思维的架构师，能够在一开始设计时就考虑到后续架构的演化特性，并且将灵活应对变化的能力作为架构设计的主要考量。
2. 原则
原则1： KISS (Keep it simple,stupid) 和保持每件事情都尽可能的简单，用最简单的解决方案来解决问题。但是如果不知道什么是复杂，怎么知道如何保持简单？很多团队声称的 KISS，不过是偷懒的借口。如果项目不死，总有一天团队需要为前面的潦草、Simple 和 Stupid 埋单。
原则2：YAGNI（你不需要它）原则 ，只在需要时构建。
原则3：先保证能够正常运行，然后优化它使其更好，最后逐渐让它变得完美。使用迭代开发，采用敏捷开发模式。为每个功能制定一个开发周期（最多2周），然后不断迭代。
原则4：自动化测试是构建稳定、高质量产品的唯一方法。通过自动化测试提升创造力，所有一切都可以自动化！在设计时应当好好考虑自动化。
原则5：功能的设计和测试尽可能独立。如果在设计时考虑到这一点，长远来看，它将省去很多麻烦，否则只有一切构建完成时你才可以开始测试整个系统。此外，遵循这个原则，版本发布也会更加顺利。
步骤
- 搞清楚要解决的现实问题。
- 确定边界。
- 用分解、抽象、结构化的思维来拆分问题并梳理好每个流程。
- 借助集成、复用、分层思维给出你认为最合理的技术实现方案。形成最终一份完整的架构。
- 根据对未来的预判对架构方案进行局部修正，直到合理。
