目录
1、设计很重要
2、架构设计的目的是什么？
3、架构设计的主要内容是什么？
4、架构设计有什么原则？
5、架构师的职责是什么？
6、架构设计过程如何？
全局分析阶段
设计方案阶段
架构设计阶段-应用架构
架构设计阶段-部署架构
架构设计阶段-数据架构
架构设计阶段-技术架构
详细设计阶段
7、有什么方法能做的更好？
8、还需要掌握什么知识？
也许您对软件设计存在一些疑惑，或者缺乏明确思路，那么本文将非常适合您。
参考资料-架构设计之道：架构设计之道
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、架构设计过程如何？
过程：全局分析业务 → 设计方案→ 概要设计→ 详细设计→ 补充设计
视角：业务级 → 系统级 → 应用级 → 模块级 → 技术级 → 代码级 → 实施级；
架构师的协作链路较长，每一个过程都应该留下资料，越下游的角色往往需要更全面的资料；架构设计文档应该包含架构师参与的所有环节，以及这些环节产生的图文说明；不仅仅是空洞的结果，应该包含架构师的思路和想法；
全局分析阶段
这阶段需要对业务需求进行全面分析，需要将名词罗列出来，区分名词是功能、流程、名词、参与者的哪一种。再通过分析业务的本质并找到其中的关键名词，关键的名词被称之为领域，可以围绕关键的领域构建业务模型；
在这个过程中，需要统一语言、识别核心领域、按照相关性将功能归属到对应的领域，对领域之间的关系做出必要的描述，输出物是名词与解释、领域以及拥有的能力，业务架构。
名词的概念必须是清晰的，领域的职责必须是明确的，领域拥有的能力必须是相关的；
其中业务架构可按照场景层、功能层、领域层、依赖层划分，例如下图；
设计方案阶段
在完成全局分析之后，我们应该设计技术方案，尽可能提供多个备选方案的图文说明。需要对备选方案做充分的优劣分析，最终取舍一项最合适的方案，没有被选择的方案（或者取舍的部分）也要被说明；
我们需要找到各项约束条件（时间、人力、硬件等），评估在约束条件允许的情况下，哪个备选方案更合适，我们可能考虑如下方面：
方案对业务影响：主要判断需求覆盖程度、实现业务的短期目标、考虑业务的长期目标；
方案的技术需求：安全是否满足、性能是否满足、规模是否满足、可维护性；
方案的可扩展性、方案的复杂程度、方案是否能够演进、方案演进成本如何（高成本的 慎重考虑）、方案的影响力传播如何（对上下游影响较大的 慎重考虑）；
架构设计阶段-应用架构
用以说明当前系统的元素（系统、子系统、模块，组件）以及他们之间的关系（层次关系、依赖关系）；在DDD实战中，可以用限界上下文、领域、子领域等概念；
重点是将可复用的组件抽象后下沉，越往下层越是稳定和通用，由上层承接不稳定的业务；
应用架构图体现了层次关系，以及不完全体现了依赖关系，依赖只能是上层依赖下层，示例如下图
架构设计阶段-部署架构
用以说明支持应用所需要的硬件能力、以及外部中间件、网络、机房等情况；可参考下面两张图；
架构设计阶段-数据架构
描述数据资产结构、存储、流转、灾备的情况；最常用的是ER图；
架构设计阶段-技术架构
描述一些关键技术的说明，比如性能、安全、交互等；
描述技术选型和代码框架的说明，比如DDD推荐的菱形对称架构，文字和图片描述都可以；
详细设计阶段
详细设计是非常必要的，详细设计是对质量的把关、是对研发落地的指导；
这部分涉及的内容较多，比如服务、事件、接口、实体和值对象、时序图、数据库设计等等；
关于聚合：使用聚合的试错成本比较高、在缺乏领域专家以及业务变化频繁的情况下，不建议使用聚合，聚合的能力可以放到领域服务；
领域服务、领域事件
时序图
实体关系图
7、有什么方法能做的更好？
推荐《领域驱动设计》为辅助思想
学习和使用领域驱动设计，使用正确的方法梳理和理解业务，并落实到架构过程；
尽早的介入，从业务领域建模和在产品方案阶段介入、推动领域知识的传递、为后续做好铺垫；
积累业务能力和洞察力，需要识别关键部分与辅助部分、预料可扩展部分与不变部分，识别水平能力与垂直扩展；
对于架构设计产物，不要只画图，多辅以文字表述图中内容
8、还需要掌握什么知识？
业务知识：业务架构（是对当前业务、领域、能力、流程、参与者、场景的介绍），现状架构（是对当前架构的描述，可以包含应用架构、技术架构、部署架构、数据架构等），愿景架构（ 是架构应该演进到的完美情况），存在问题（现在面对的痛点、无用部分、缺陷部分）
高性能：多线程、队列、缓存、分片、异步化，前置化、静态化、预处理；
高可用：限流、降级、冗余、灾备、回滚、灰度；
扩展性：多态、防腐，依赖反转（业务身份、扩展点、SPI），抽象化（比如流程引擎、规则引擎等）、事件驱动、设计模式；
本文盗图甚多，来源已失，无法链接，还请见谅。