架构设计系列文章，请参见连接。
背景
一个人怎么做一件事情，取决于一个人怎么认知这件事情。对于架构设计来说也是一样的。到现在软件业界对架构没有一个统一的认知，而在没有统一认知的情况下怎样去做架构设计这件事就成了一件无解事情。
作者本人对与架构设计的认知是：技术架构设计是业务架构的一个组成部分，由业务去规划业务蓝图、发展规划等内容后由技术架构设计将整体架构填充起来。所以，就有了业务架构设计完成后，“灵魂”就诞生了，IT架构则是根据灵魂的需要设计“容器”。
对于企业的业务架构设计的方法论以及理念有很多方法论，例如：ZachMan、TOGAF
、EAF、DODAF等。这里就不讨论关于这部分了。
架构设计理念说明方法
在中国传统哲学理念中有：道、法、术、器。道是战略思想、战略规划，体现在以怎样的理念、价值观去指导设计架构工作。法是实现战略的最根本的战术方法、指导方针、思路，体现在架构设计过程中模式。术是具体的手段、具体的行为方式等，体现在架构设计应该遵循的原则。器是工具、体现在架构设计中真正落地事需要进行的分析与设计的方法与工具。
还有这么几句：
道以明向，法以立本，术以立策，势以立人，器以成事。
用最精炼的化将道法术器的作用与关系说明的清晰了然。
在软件界技术、方法、思想都处于高速发展的阶段来说，怎样确保自己不被技术的滚滚洪流所冲倒。借鉴道不易，法简易，术变易，那么通晓架构设计最基本的道就可以长久的屹立不倒。下面会按照道法术器的层级关系分别说明这几部分。
道：架构设计理念
- 架构本质
架构的本质是管理复杂性，微服务本身也是架构演化的结果
- 道
道解决的是什么是正确的事，法、术、势、器解决的是如何将事情做正确。是不是感觉到有了这套方法论之后就再也不怕做错事了！作者就是以架构设计理念的方法指导具体架构设计工作。以这种方式使工作更加强有责任感与更加高效，并以这种态度开展与推进具体的工作。
通过对平常工作过程中接触到的项目、系统、模块的架构设计的经验与教训的总结，再综合软件业界对于架构设计工作的理念与思想，在加上作者对软件架构设计的理解。最终总结出在实施软件架构设计时需要注意四个要点：$\color{red}{简单，有效，可靠，完善}$。
这四个要点对于架构设计工作至关重要，它覆盖了架构设计工作的方方面面。而且这四个要点在架构设计中并不是孤立的，它们之间有着千丝万缕的联系。简单的架构在有效的解决业务问题的基础上，同时能够提供完备解决方案并且提供可靠的业务服务能力才是好架构。再有：只有简单的架构才能最可靠的，设计过于复杂会产生各种不可控的问题。只有完善的架构才能为提供有效的业务解决方案等等。
- 简单
以最简单的方式实现，最大限度的降低复杂度。方便开发与验证，提供简单的设计模式，有利于系统内的所有人员达成一致，为高效的组织提供可能。
- 有效
以有效的方式解决问题。不进行过度设计，以免不必要的复杂度加入到系统中。在精益中提到的拒绝浪费，以最有效的方式完成设计拒绝任何形式的浪费。
- 可靠
提供可靠的解决方案在现有的场景下选择最适合，最实用的技术搭建可靠的解决方案。
- 完备
完善的解决问题，不遗留任何问题。支持快速决策的要求，提前考虑可持续发展，异常场景等需要决策的内容。在精益中提倡系统性的思维，根据系统整体情况为系统建设提供完善的解决方案。
法：落地指导
法在战略之下提供对于战术方法、指导方针、思路级别的工作指导。对于真正下手进行架构设计前必须明白的一些事情，也是在架构设计过程中用来规范落地中的思路问题的解决方案。
- 架构落地驱动力
在之前读的几本书中说明了不同的架构设计驱动方法，这些书以不同的方式描述在架构设计过程中以怎样的驱动力来驱动架构设计。
以风险驱动为主的《恰如气氛的架构设计：风险驱动的设计方法》说明在风险不足的情况下不要过多的设计，在风险来之前做推迟决策，在风险来临时做快速决策的方法。
以演进式思路的《演进式架构》说明在UVCA时代软件技术从业人员应该以怎样的方式去应对变化，以达到变化驱动的设计的方法。
以业务为灵魂以技术为肉体的《企业即业务架构设计》说明在有业务这个灵魂的时候技术才是有意义的。并以业务驱动的设计方式推进技术设计的进行。
还有最重磅级的《领域驱动设计：软件核心复杂度应对之道》，它帮我们建立认识世界的大门。
几本书说明了不同的设计驱动力，在不同的驱动力下会要求作出不同的架构设计。这就是需要进行模式思维的时候。
- 合适的就是最好的
马丁.福勒的《Is Design Dead?》已经很好的阐述了什么样的设计是好设计，作者在这里只是借鉴最终结论：合适的设计就是最好的设计。
- 模式思维
模式是前人通过不断的努力在某个特定的方面总结固定搭配或流程。像设计模式，架构模式都是这一类的。第一点需要知道在什么场景下哪些模式是最适用的。第二不要拘泥与模式中具体的知道要做到将模式融入到实际的工作中。总结起来就是：规则对于智者来说是指导，对于愚者来说是遵从。
- 没有万能的银弹
在萨姆·纽曼的《微服务设计》一书中明确的说明没有万能的银弹，也不可能有万能的银弹。这就需要从业人员用自己的分析能力，分析出具体业务中的问题并根据问题形成方案。而不是利用某一个银弹去指导自己一切工作。
架构设计工作推进方式
- 透明
系统是完全透明的。可以让所有人都能很好的看懂，很快的理解系统。明确的表明系统结构，提供可以可视化，可被评估，可被改进的基础。
- 合作
对于企业内部、外部业务的支持都是需要通过架构体现出来的。为公司的合作建立基础，在技术体系的基础上，更快的得到共识，更快的达到统一。
- 开放
架构开放，任何人、任何时间、任何地点都可以提出改进意见。为我们的技术体系建设提供智慧。促进形成开放的组织，开放的过程。为公司建设更加主人公意识的团队与过程。
- 体系
建立完善的体系。帮助建立完善的思维体系。减少碎片化对系统带来的未知感与不确定感。体系中可以包括：业务，工程，技术，组织等软件工程中的内容。
术：设计工作指导原则
术是具体的手段、具体的行为方式等，体现在架构设计应该遵循的原则。要让架构表现哪些内容才能让架构看起来更符合上面的道、法的内容。一个系统架构设计最普遍的要求是安全、稳定、性能和规范这四个大点，还有可能包括提高工程效率、实现业务目标等。要满足这些点需要让架构体现出一下四点：数据化、可视化、体系化、标准化。
- 数据化
方便进行量化的分析与决策支持工作。这里就需要将业务指标和技术指标全部进行设计与验证。这些指标可以通过可视化进行可视化。
- 可视化
以直观的方式去获取想要看到的，关心的数据。在可视化中运维需要可视化，帮助快速定位运维问题、以及线上问题快速定位能力。更加方便之后进行弹性伸缩，方面的方法制定。再有业务可视化，基于数据化的内容进行业务数据的展示工作。
- 体系化
制定技术目标，在目标的基础上进行相关的开发与设计工作。明确框架不可能保证系统的可用性，性能，安全，可扩展性。这些是有架构去完成的。所以，需要一套架构。
- 标准化
统一公司内部的技术栈，以及技术栈上相关的组件。可以降低技术团队沟通以及技术选型所造成的不一致问题，标准化服务划分标准，为公司构建共同的设计平台以及构建功能的方法。标准化包划分标准，为代码的可读性，标准化质量标准，规范化质量过程中各个方面的质量标准。方便进行验证与实施。标准化运维。用来规范实施过程以及运维过程。
如需四化的具体内容可以留言。
器：方法与工具
对于一个技术人来说以什么样的底子支撑架构设计？第一条就是需要对技术有全面的认知。而这个认知不是一时半会就可以形成的，需要有完善的知识体系。例如作者正在输出的《微服务实践》系列文章就是对于技术知识体系的梳理与完善。完善自己的技术知识体系有一个标准，这个标准就是对与统一领域不同技术实现的应用方式都有自己的见解。
对事物的分析方法：分解、抽象、知识。借用这三个方法可以对世间的任何事情进行分析与设计工作。这是《恰如其分的架构设计》一书中提出的，具体内容可以参见此书。
接下来就是最实际的工作：以那种分析方法分析系统中特性，怎样构建模型，构建什么样的模型，以什么方法进行设计。可以通过MDA、DDD进行业务的分析，以UML进行模型构建，以设计原则，架构模式、设计模式指导进行架构设计。
总结
对于个人来说懵懵懂懂的过日子可以，但活明白自己的人生才是更重要的。对于自己所热爱的内容需要以不断的热忱、好奇心去探索它。并为能够做好它的而感到骄傲。而做好热爱的事情不能盲目的去做，需要有自己对这件事的理想、在理想的指导下形成我们对事情的追求、以所追求的目标指导自己的工作、为达成目标寻找并实践各种方法论。这样才能真正的从理想落地到实施上。并在实施过程中不迷失自己。
