原副标题：怎样做体系结构？
译者 | 天猫云开发人员-天猫信息技术 董建
或许您对应用软件结构设计存有一些困惑，或者缺少明晰路子，那么责任编辑将适于您。
1、结构设计很关键
他们能看一下邻近的表达方式，那些好的东西，她们并不能纯天然存有，都是被结构设计出来的，因此结构设计是缔造和明显改善表达方式的关键过程。结构设计的关键之处是，起初的结构设计常常下定决心最后的结果，甚至下定决心着表达方式的长年的产业发展。比如两个国际品牌的智能手机之间，她们可以使用同一代工，但她们差别在结构设计时就已经下定决心了。
体系结构也是如此，我见过很多的应用软件产品，她们历经了许多年的重构，在没有完全解构的情况下，仍旧难以改变起初结构设计样子，起初的结构设计下定决心了长年的产业发展。而对于销售业务广度谐振的控制系统，解构生产成本十分高，风险也十分大，变动也更为不确认，所以要更为倚重结构设计。
他们要谋求更快的技术计划，促进构架的良性循环重构，每一步都是历经广度思索的，而体系结构方法是协助他们思索的架构。
通过做体系结构，他们应该提高应用软件的产品质量和工作效率，减少风险和生产成本。
2、体系结构的目地是什么？
是为了化解应用软件产品维数带来的问题（构架的最终目标是用作管理复杂程度、善变性和不稳定性，以保证在长年的控制系统形成过程中，一部份构架的变动不能对其他部份产生无谓的消极影响。这样做能保证销售业务和研制工作效率的灵巧，让应用领域的善变部份能够频密地变动，对应用领域的其他部份的影响尽量Arreau。）
要集中在以下三个方面：
销售业务维数：流程多，参与者多、状态和变量多等；由销售业务本身下定决心，但销售业务复杂不代表应用软件产品复杂，比如工作流引擎并不复杂，但他能做十分复杂的销售业务，在面对复杂销售业务时，他们常使用抽象思维，不要让应用软件逻辑与销售业务逻辑绑定在一起。
技术维数：高性能、高可用、高可扩展、安全，生产成本、规模等；这部份维数常常由技术本身下定决心，也应该由技术本身化解，通常是采用更合理的架构和工具；避免这些技术特性穿透到应用领域层。也能有所取舍，在不同销售业务情况下，采用不同的实现程度。
结构设计维数：职责不是最小的完备的、概念不清晰的、层次不清的、销售业务逻辑与技术实现绑定的，组件过多以及关联依赖复杂的；这部份是由结构设计不合理导致的，也是对销售业务控制系统影响最大的一部份，要通过良好的结构设计来化解。
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内部大乱斗不休止
中文编程语言——青语言开源发布
这里有最新开源资讯、应用软件更新、技术干货等内容
