架构设计系列文章，请参见连接。
背景
写出一份富有感情并对实际工作有指导意义的文章非常不容易。因为工作忙没有时间去梳理与整理这方面的思路是主要原因，但也有人越来越懒、越来越多事情要想造成的问题。而最近会重拾起写作这件事，因为只有对自己的提升才是对自己最大的认可与投资。
随着工作方向的变化，作者本人也对与架构设计的工作遗忘了很多。为了更好的为实际工作做指导，并且时刻保持有效、可靠的架构决策作者准备把之前在各种情况下做的架构设计过程做一个抽象并记录下来。
前面的文章中有关于架构设计理念的描述，架构设计理念是对架构设计的一个高度抽象。也会有架构师知识体系这样纯知识体系的内容。而对于一个架构师应该怎样进行架构设计，架构设计的过程是什么样的业界也有很完善的体系，比如说：MDD、DDD、风险驱动设计，演进式架构等。而本篇是作者在实际工作中真正使用到的架构设计过程。
因作者的知识面、工作方向、从业经验的影响，本文中肯定会有各种遗漏和欠缺。但这里的思路也代表着一种实际实践过程中的指导，故还是写下来。
方向
这里先需要明确一下本篇文章中架构设计具体是指那个方向的架构设计。软件的架构设计可以分为：企业架构（EA），业务架构（BA），技术架构（TA）。三个不同的方向就会有三个不同的设计过程与设计结果，所以这里简单的说一下这三个方向：
企业架构规划整个企业的业务蓝图。对蓝图进行拆解与实施。例如：TOGAF，ZACHMAN这样的EA。
业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。（TOGAF中的定义）
IT架构对于企业架构与业务架构具体落地到技术层面时应该使用技术结构。
技术架构对于纯技术领域中关于架构的内容。例如：区块链的架构，人工智能的架构。
对于国内从事架构设计方向的大多数人来说最主要的方向还是集中在IT架构上。所以这里也集中说明IT架构的设计过程与方法。
步骤
-
问题域的定义：
摆在架构师面前的问题是架构需要设计哪些东西？架构要涉及到多少细节？怎样的设计才能让团队顺利实施？对于一个产品来讲技术资产应该怎样进行管理？
针对这些问题，或者更多的架构设计问题应该以怎样的步骤去解决问题？怎样的工具去解决问题？
-
解决域工具：
针对上面的问题需要有实际的工具和方法去指导架构师应该怎样完成工作，下面结合过程和方法对这部分进行说明：
-
软件需求=功能需求+非功能需求+约束：
每个项目都有自己的特点，在接触一个新的项目或着接收一个遗留系统的时候最长听见的一句话是：我们的系统逻辑不像其他的，我们的业务逻辑很复杂。而在架构设计前期最主要的工作就是了解功能、非功能、约束方面的内容。例如：一个业务流程是业务功能方面的需求，整体系统设计容量或现阶段容量、稳定性、安全方面就是非功能需求，再比如是不是有必须要在遗留系统里面保留的内容，是不是遗留系统不可能一步替换掉，用户的操作方式是否可以变更这个就是约束。
这部分主要是为了了解系统需要解决的问题，不管是业务问题还是技术问题，还是其他问题都需要了解清楚。在了解清楚问题域的情况下才能对整体系统有系统型的设计。
而在软件需求阶段有两个比较重要的产出物：容量评估，约束列表。
容量评估实践过程，可以参考：滴滴内部线上系统的容量评估方法，微服务负载保护设计方法，还有作者写的帮Stack Overflow评估一下性能指标。
约束列表就是将项目/产品中关于必须遵守的约定进行记录，以方便之后进行查询与参照。 -
设计方法选择：
设计方法可以选择数据驱动设计（设计数据流，数据存储结构等），模型驱动设计（UML），领域驱动设计（DDD），风险驱动设计（RDD），演进式设计（EDD）。在一个项目中不可能只选择一种设计方法进行设计工作，所以一般会采用多种方式结合的方式进行架构设计工作。 -
架构模式选择：
采用云架构还是采用微服务架构其实是需要进行抉择的。就像在IoT项目中最好的方式是使用《控制环路模式》去做相关的架构设计。在区块链系统的架构中最好使用P2P的方式进行架构设计。所以，需要根据不同的项目采用不同的架构模式进行设计。不过选择架构模式是也可能会遇到约束的问题，比如说公司/客户要求必须使用微服务进行设计。针对这部分有要求的项目/产品就需要遵守约束中的规定。
在选择架构模式是也不是只选择一种架构模式，肯定是需要选择一个主架构模式，再选择几个辅助架构模式，使用多种架构模式结合的方式进行架构的设计工作。 -
架构全景图
选择完成设计方法、架构模式的选择之后，就需要制定一张完整的架构全景图。全景图包括：业务全景图，架构全景图。
业务蓝图可以代表业务的整体情况。
架构全景图代表架构中对于业务的拆分以及业务拆分之间的关系。 -
填充细节：
在有了全景图之后，就需要对架构设计的细节进行填充。填充的内容包括：业务拆解、业务核心流程设计、技术选型、非功能设计。 - 架构设计演进：
对于软件系统搭建完成之后，就意味着架构已经开始老化了。而应对架构老化的问题就必须进行架构的演进。而架构演化的过程需要有合适的时候将功能/代码下线。所以这个阶段就是服务治理的过程。
以上描述的是项目架构从0到1的过程。而对于架构从1到100的过程就需要持续的演进动作。而演进过程中要谨防的是架构的腐化，防止架构中被遗留代码/服务/项目限制架构的发展。
实施
上面已经说明了架构设计的步骤，而现实中对于这个过程的实施也会有所不同。这里再次说明一下具体实施过程中要做的事情：
- 非功能需求确认
询问客户系统中的用户数、sku/spu数、交易数、活跃时间、单页面停留时间等信息。 - 容量评估
收集到这些信息之后再根据上面提供的容量评估方法进行容量评估即可。 - 整体架构设计
选择架构模式、技术栈后将整体架构按照架构模式的内容拆分为架构模式中所需要的组件。 - 核心流程设计
进行细节核心流程的设计。比如说交易系统的交易流程。 - 核心存储结构设计
根据容量评估进行存储的设计。包括：对象存储，内容发布网络，缓存，数据库等。 - 可靠性、性能、稳定性设计
还是根据容量评估进行非功能型方面的设计。
对于完全新系统来说可以进行这样的设计过程，但对于需要兼容遗留系统的设计过程需要考虑遗留系统的特点。遗留系统最可能使用的方式是使用Sidecar模式进行设计。
总结
前面有关于架构设计原则指导，还有架构师的知识体系，这里又说明了个人的架构设计过程。也算是相对完善的阐述了作者对于架构设计的理解。不过之后还是会输出关于其他方法论的具体理解的文章。
参考
为什么大部分人做不了架构师？这2点是关键
企业架构方法论可以简化吗？
架构师及其目标在软件项目中的挫折感
给敏捷团队中的架构师的 10 个建议
架构：系统的概要设计
架构师成功沟通的 3 个关键
