来源 | OSCHINA 社区
作者 | 京东云开发者-京东科技 董建
原文链接：https://my.oschina.net/u/4090830/blog/9869453
也许您对软件设计存在一些疑惑，或者缺乏明确思路，那么本文将非常适合您。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），抽象化（比如流程引擎、规则引擎等）、事件驱动、设计模式；
国区JetBrains产品最新定价公布，比美区贵
Rust内部大乱斗不休止
中文编程语言——青语言开源发布
点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦
