兴许您对软件设计存在一些纳闷，或者不足明确思路，那么本文将非常适合您。
1、设计很重要
咱们能够看一下周边的事物，那些好的货色，他们并不会人造存在，都是被设计进去的，因而设计就是发明和改善事物的重要过程。设计的重要之处在于，最后的设计往往决定最终的后果，甚至决定着事物的长期的倒退。例如两个品牌的手机之间，他们能够应用同一个代工厂，但他们差别在设计时就曾经决定了。
架构设计也是如此，我见过很多的软件系统，他们通过了很多年的演进，在没有齐全重构的状况下，始终无奈扭转最后设计模样，最后的设计决定了长期的倒退。而对于业务深度耦合的零碎，重构老本十分高，危险也十分大，变动也更加不确定，所以要更加器重设计。
咱们要寻求更好的技术计划，推动架构的良性演进，每一步都是通过深度思考的，而架构设计办法就是帮忙咱们思考的框架。
通过做架构设计，咱们应该晋升软件的品质和效率，升高危险和老本。
2、架构设计的目标是什么？
是为了解决软件系统复杂度带来的问题 （架构的指标是用于治理复杂性、易变性和不确定性，以确保在长期的零碎演化过程中，一部分架构的变动不会对其它局部产生不必要的负面影响。这样做能够确保业务和研发效率的麻利，让利用的易变局部可能频繁地变动，对利用的其它局部的影响尽可能地小。）
要解决复杂度问题，首先须要辨认复杂度的起源，次要集中在以下三个方面：
业务复杂度 ：流程多，参与者多、状态和变量多等；由业务自身决定，但业务简单不代表软件系统简单，例如工作流引擎并不简单，但他能够做非常复杂的业务，在面对简单业务时，咱们常应用抽象思维，不要让软件逻辑与业务逻辑绑定在一起。
技术复杂度 ：高性能、高可用、高可扩大、平安，老本、规模等；这部分复杂度经常由技术自身决定，也应该由技术自身解决，通常是采纳更正当的框架和工具；防止这些技术个性穿透到应用层。也能够有所取舍，在不同业务状况下，采纳不同的实现水平。
设计复杂度 ：职责不是最小的齐备的、概念不清晰的、档次不清的、业务逻辑与技术实现绑定的，组件过多以及关联依赖简单的；这部分是由设计不合理导致的，也是对业务零碎影响最大的一部分，要通过良好的设计来解决。
3、架构设计的次要内容是什么？
找到零碎中的元素并搞清楚他们之间关系 （如果咱们不晓得零碎是怎么运行的，那么他肯定是很简单的。对于宏大的软件系统，如何才能够被掌控？这就须要将大零碎合成为很元素，每个元素须要足够简略，并且元素与元素之间的关系清晰）
软件架构是一种构造，构造中蕴含了一些元素和元素之间的关系形容；
元素的品种：零碎、子系统、模块，组件、服务、类、接口 …
关系的品种：档次关系、数据关系、调用关系、影响力关系 …
“ 架构示意对一个零碎的成型起关键作用的设计决策，架构定零碎根本就成型了，这里的关键性能够由变动的老本来决定。”– Grady Booch. ）
“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” — Grady Booch.
4、架构设计有什么准则？
适合准则：“适合优于业界当先”。真正优良的架构都是在企业以后人力、条件、业务等各种束缚下设计进去的，可能正当地将资源整合在一起并施展出最大效用，并且可能疾速落地。
简略准则：“简略优于简单”。优先应用间接的不简单的计划解决问题；
演变准则：“演变优于一步到位”。软件须要依据业务的倒退一直地变动，架构要一直地在理论利用过程中迭代，在某个阶段必然有所取舍，但架构的演变必须是低成本的，当业务发生变化时可能最高效的迭代；在这个过程中修复缺点的设计，积攒优良的设计；
5、架构师的职责是什么？
业务剖析：梳理对业务和技术的了解和判断、造成业务畛域常识、明确的业务指标和实质的业务诉求；
零碎建设：升高零碎复杂性、规划系统远期架构、推动架构的正当演变；
技术计划：抉择适合的技术、提供对业务的解决方案，把控全局，包含品质、效率、老本、危险；
关键问题：攻克难点，解决关键问题，领导研发落地；
常识积淀：以体系化的表达方式，面向不同人员的视图语言，继续欠缺常识零碎；
6、架构设计过程如何？
过程 ：全局剖析业务 → 设计方案 → 概要设计 → 具体设计 → 补充设计
视角 ：业务级 → 零碎级 → 利用级 → 模块级 → 技术级 → 代码级 → 施行级；
架构师的合作链路较长，每一个过程都应该留下材料，越上游的角色往往须要更全面的材料；架构设计文档应该蕴含架构师参加的所有环节，以及这些环节产生的图文阐明；不仅仅是空洞的后果，应该蕴含架构师的思路和想法；
全局分析阶段
这阶段须要对业务需要进行全面剖析，须要将名词列举进去，辨别名词是性能、流程、名词、参与者的哪一种。再通过剖析业务的实质并找到其中的要害名词，要害的名词被称之为畛域，能够围绕要害的畛域构建业务模型；
在这个过程中，须要对立语言、辨认外围畛域、依照相关性将性能归属到对应的畛域，对畛域之间的关系做出必要的形容，输入物是名词与解释、畛域以及领有的能力，业务架构。
名词的概念必须是清晰的，畛域的职责必须是明确的，畛域领有的能力必须是相干的；
其中业务架构可依照场景层、性能层、畛域层、依赖层划分，例如下图；
设计方案阶段
在实现全局剖析之后，咱们应该设计技术计划，尽可能提供多个备选计划的图文阐明。须要对备选计划做充沛的优劣剖析，最终取舍一项最合适的计划，没有被抉择的计划（或者取舍的局部）也要被阐明；
咱们须要找到各项约束条件（工夫、人力、硬件等），评估在约束条件容许的状况下，哪个备选计划更适合，咱们可能思考如下方面：
计划对业务影响：次要判断需要笼罩水平、实现业务的短期指标、思考业务的长期指标；
计划的技术需要：平安是否满足、性能是否满足、规模是否满足、可维护性；
计划的可扩展性、计划的复杂程度、计划是否可能演进、计划演进老本如何（高老本的 慎重考虑）、计划的影响力流传如何（对上下游影响较大的 慎重考虑）；
架构设计阶段 - 利用架构
用以阐明以后零碎的元素（零碎、子系统、模块，组件）以及他们之间的关系（档次关系、依赖关系）
重点是将可复用的组件形象后下沉，越往上层越是稳固和通用，由下层承接不稳固的业务；
利用架构图体现了档次关系，以及不齐全体现了依赖关系，依赖只能是下层依赖上层，示例如下图
架构设计阶段 - 部署架构
用以阐明反对利用所须要的硬件能力、以及内部中间件、网络、机房等状况；可参考上面两张图；
架构设计阶段 - 数据架构
形容数据资产构造、存储、流转、灾备的状况；最罕用的是 ER 图；
架构设计阶段 - 技术架构
形容一些关键技术的阐明，比方性能、平安、交互等；
形容技术选型和代码框架的阐明，比方 DDD 举荐的菱形对称架构，文字和图片形容都能够；
具体设计阶段
具体设计是对品质的把关、是对研发落地的领导；
这部分波及的内容较多，比方服务、事件、接口、实体和值对象、时序图、数据库设计等等；
畛域服务、畛域事件
时序图
实体关系图
7、有什么办法能做的更好？
学习和应用畛域驱动设计，应用正确的办法梳理和了解业务，并落实到架构过程；
尽早的染指，从业务领域建模和在产品计划阶段染指、推动畛域常识的传递、为后续做好铺垫；
积攒业务能力和洞察力，须要辨认要害局部与辅助局部、意料可扩大局部与不变局部，辨认程度能力与垂直扩大；
对于架构设计产物，不要只画图，多辅以文字表述图中内容；
8、还须要把握什么常识？
业务知识：业务架构（是对以后业务、畛域、能力、流程、参与者、场景的介绍），现状架构（是对以后架构的形容，能够蕴含利用架构、技术架构、部署架构、数据架构等），愿景架构（是架构应该演进到的完满状况），存在问题（当初面对的痛点、无用局部、缺点局部）
高性能：多线程、队列、缓存、分片、异步化，前置化、动态化、预处理；
高可用：限流、降级、冗余、灾备、回滚、灰度；
扩展性：多态、防腐，依赖反转（业务身份、扩大点、SPI），抽象化（比方流程引擎、规定引擎等）、事件驱动、设计模式；
本文局部图片来源于互联网
作者：京东科技 董健
起源：京东云开发者社区