原副标题：详解繁杂销售业务控制系统的构架结构设计
译者 | 天猫云开发人员-天猫信息技术 皮亮
1. 甚么是繁杂控制系统
他们时常提及繁杂控制系统，所以究竟甚么是繁杂控制系统。他们看下维基百科的表述：繁杂控制系统（英语：complex system），又称为A43EI235E控制系统，是指由很多可能将交互作用的共同组成成份所共同组成的控制系统。特别强调了三点：
由点共同组成 点间有各式各样关连
三点的体量和繁杂性间接下定决心了控制系统的繁杂程度。比如说就拿他们的B2C控制系统总括，分为很多部份，货品、库存量、订货、订货、仓储、财务管理工作，那个而已大的进行分类，除了特别针对 C 端网络营销、团体会员、买回、售后服务等管理工作体系，特别针对 B 端店家进驻、管理工作等管理工作体系。各部份、管理工作体系间有著密不可分的联系，虽说之繁杂控制系统了。总之了，相比之下闻所未闻那些，随著销售业务繁杂性的急速提高，整座控制系统的繁杂性也会越发繁杂。
2. 甚么是构架
日常生活中他们时常谈到 “构架”，所以究竟甚么是 “构架”，Robert C.Martin《构架干净之道》中的表述：应用软件构架是指结构设计应用软件的数人应用软件突显的花纹，那个花纹是指控制系统怎样被分割为模块 (Components)，各模块怎样排序（Arrangement），模块间怎样沟通（Communication，通讯），维基百科百科的表述：有关应用软件整体结构与模块的抽象描述，用于指导大型应用软件控制系统各方面的结构设计，IEEE 的表述：构架 = 共同组成单元的结构 + 共同组成单元的关系 + 原则和指南，总体来看会包括几个内容：
整体：特别强调部份的共同组成，特别强调合力 规则：特别强调部份间有关连关系，有规则，有约束 通信：特别强调部份间有往来，有交互这样说来，他们人类社会本身就是一个社会构架，各式各样职责、分工、圈层，就他们的应用软件控制系统来说，DDD 是构架，MVC 也是构架，大数据结构设计也有大数据的构架。所以构架无处不在，好的构架能够对特定的问题，特定的领域起到规范和指导作用。
3. 构架的本质
他们知道，构架那个词是源于建筑行业的，英文原词是：Architecture，维基百科百科上的解释是规划、结构设计和建造建筑物的过程及产物。那他们就用建筑行业来理解一下。建房子对大家而言再熟悉不过了，那他们盖个小平层、盖个两层小高层、盖个 5 层小高层、搞个 10 层、盖个几百层的摩天大楼的过程、因素、风险是完全不同的。盖摩天大楼需要付出的成本更高，过程中的不确定性更多，挑战和风险也更大，例如怎样选地、选择甚么样的结构，怎样承重，采光怎样控制，优化、怎样取暖，怎样上水、排水，怎样通风，怎样避震等等。那些东西他们考虑的越多，房子未来的质量，可控性也会越好。
所以构架本质上就是一种指导型的约束，以约定整体和部份、部份和部份间的关系，以使整体更加稳定，更加可靠。
4. 构架进行分类
他们上面举的例子他们可以叫做建筑构架，实际上构架有很多种类型，比如说销售业务构架，应用构架，技术构架，数据构架等。单个构架进行分类，站在不同的维度也会有不同的看法，繁杂性也会有相当大的区别。比如说企业级构架能够凸显出公司的整体战略，销售业务涉及情况，分布情况，发力情况。而某一个单一的销售业务线也同样有自己的销售业务构架，凸显单独销售业务自己的销售业务目标、战略等。应用构架、技术构架也是同理，会有不同层面视野的构架。他们下面就以销售业务线内部视角对他们常见的构架分离进行下简单的说明。
4.1. 销售业务构架
说到销售业务构架，偏顶层结构设计了，销售业务的表述和分割甚至会影响到整座公司整体组织构架的设立和关系。销售业务构架偏向销售业务领域分割，模型结构设计，对整体销售业务进行语言转化，内化为领域通用语言。
4.2. 应用构架
体现应用内部的结构关系。应用怎样进行结构设计，包括模块怎样分割，功能怎样实现，技术怎样支撑，数据怎样展示，流程怎样表述，逻辑怎样实现，数据怎样存储等等，都是应用构架的范畴。他们时常说到的 MVC、分层构架、CQRS、DDD 传统洋葱圈构架、DDD 六边形构架都可以归结为应用构架的范畴。
4.3. 技术构架
技术构架不一定局限于单个应用内部，尤其是当前微服务构架时代，服务间怎样交互，服务怎样治理，数据怎样存储，缓存怎样构建等等，都是技术构架的范畴。技术构架给应用和销售业务构架提供了一个技术基础，以使销售业务更好的发展，更健壮的迭代，发展。
5. 构架需要考虑哪些因素
5.1. 功能性需求
无论是甚么构架，他们第一时间考虑的一定是需要满足他们实际的销售业务述求的。没有需求的构架就是相当于空中楼阁，中看不中用，不切实际。这并不是真正的构架。一般来说，功能需求会间接下定决心销售业务构架，对应用和技术构架影响不大。他们的构架必须能够正确、完整地对功能性需求起到支撑作用。
5.2. 非功能性需求
构架满足功能性需求是第一要务，同时他们需要考虑能够稳定、可靠的支持功能，也就是他们同时需要满足一些非功能行需求，比如说性能、可靠性、扩展性、兼容性等等。
5.3. 可靠性
为了更好的服务于功能，他们需要确保构架能够稳定、高效的运行。不会时不时的出现服务崩溃或者不可用的情况。
5.4. 可用性
同样的，服务对外要始终处于可用的状态，即使单个服务实例出现问题，他们依然可以正常的对外提供服务。
5.5. 扩展性
功能性需求不是一层不变的，尤其在当今盛行敏捷的时代，需求不是一次性提出的。他们需要对控制系统、服务的整体能力有全面的定位和把控。这就需要他们的构架在新的需求出现的时候，可以方便的进行扩展支持。
5.6. 治理能力
好的构架一定是方便运营、管理和监控的。甚至微观到工程管理工作，代码一定是易于维护、扩展、协同的。
5.7. 响应性能
一般的，功能性需求都会对性能有一定的预期。那个销售业务要他们在构架上做很多工作，比如说读写分离、缓存、异步等等的介入，以满足整体构架的响应能力。
6. 繁杂控制系统怎样分析
有的同学会有误区，一想到类似这样的控制系统就觉得会有很大的繁杂性，就会考虑知难而退。但是你所认为的难不一定是难。他们都知道一句熟语：“难者不会，会者不难”，往往会由于大家经验的不同，对待同一问题的想法和思路就都会不一样。这也就是为甚么他们会在控制系统结构设计的时候，特别强调专家的重要性。尤其是目前又被逐渐提及并广泛应用的 DDD 领域驱动结构设计方法，更加提倡领域专家的重要性。这样才能够识别现实问题的繁杂性和根本痛点所在，进而能够客观合理的推导出可靠、合适的解决方案。很明显，繁杂控制系统结构设计中非常重要的两个环节：需求分析、构架结构设计。需求分析过程中，他们需要确认需求究竟要解决甚么问题，面向的角色有哪些。现在流行的分析方法要数 DDD 领域驱动的分析方法。使用 DDD 的模式分析销售业务需求大概会有几个步骤：
确认角色 确认角色功能 确认问题子域 确认模型、事件、归属 确认界限上下文
7. 繁杂控制系统的结构设计原则
8.1. 重视功能拆解，模块化结构设计，原子化结构设计
繁杂控制系统一定要进行细致功能、模块、领域的分割。每个模块的都应该有明确，单一的职责。这样他们在分析问题的时候，可以把问题聚焦在某一个范围内，不会产生太大的影响，方便整体控制系统的维护和扩展。
8.2. 纵向 + 横向拓展能力至关重要
他们做小的功能的时候，可能将不会考虑太多。但是繁杂控制系统的时候，必须要考虑很多，包括未来的功能承载、流量承载、数据体量、响应要求等等，那些都需要他们在纵向或者横向留出足够的扩展能力。那些不能一蹴而就，但是需要根据规划留有必要的扩展，以使控制系统具有长期价值。
8.3. 构架先行
对于繁杂控制系统，已经不是一个或几个流程图能解决的事情了。他们需要通过领域构架明确领域分割及领域边界，通过控制系统构架明确功能模块和功能边界，通过应用构架明确各应用的职责、边界、结构分割、依赖关系等。通过技术构架明确他们使用的技术栈及在整体控制系统中的应用边界。通过数据构架明确他们的数据存储方式、结构、数据使用方式等。
那些构架一定要清晰，明确，着眼于控制系统长期价值。
8.4. 分而治之
对于繁杂控制系统，拆分是必然的，大的问题化解成小的问题，根据领域、模块、功能的分割，他们把问题归属于不同的边界内，进行逐个攻破。小的问题得道解决，所以通过合理的依赖和组合，即可有效的解决大的问题，达到整座控制系统的建设目的。
9. 典型的繁杂问题解决构架
随著社会的急速进步，信息化模块发达，他们更需要信息化的方式去解决控制系统化的问题。早前他们更多的通过数据驱动的模式，也就是他们会先去思考会用到甚么样的结构去存储相关的数据，模型间都有甚么样依赖关系，怎么样组织数据，怎么样把数据和外围交互，那些思想也是典型的 MVC 构架。
MVC 构架迫使他们是面向视图来开发的，他们知道视图的变化最是不可控的，越是偏向于用户的东西，越是容易受到用户主观的影响。他们知道繁杂控制系统必然存在的纷繁繁杂的依赖，依赖不可能将存在于视图部份，肯定会表现为接口的依赖。对于繁杂控制系统，他们要强迫他们转换思维，强迫他们面向接口进行结构设计。结合着销售业务控制系统的繁杂性，如果想要控制系统未来具有长期价值，不得不把大的控制系统进行拆分，用统一的销售业务语言进行描述，把不可识别的问题，拆分为可识别的问题域进行解决，这也就是现在又逐渐盛行起来的领域驱动结构设计的方法。
9.1. 领域驱动结构设计
领域驱动结构设计，强迫他们不再用数据进行驱动，而是使用领域进行驱动。遇到问题，他们先进性领域上的分割和拆解。这个问题究竟属于哪个问题域，或者需要拆解到哪些问题域，然后再通过领域的组合、依赖完成最终问题的解决。
领域驱动，早在 2004 年 Eric Evans 在《Domain-Driven Design : Tackling Complexity in the Heart of Software》（领域驱动结构设计：应用软件核心繁杂性应对之道）这本书中就战略和战术两个方面进行了详细的阐述。
目前来看，对于繁杂控制系统的结构设计，领域驱动的模式利于控制系统的可持续发展。
9.2. 微服务构架
其实微服务构架就是早些时候的 SOA（面向服务构架）的一种变体。其实那个词是从 2014 年 Martin Fowler 发表的一篇文章《服务进行有选择的纵向和横向扩展，同时也避免了单个控制系统的臃肿和功能的堆叠、耦合。
9.3. 云原生构架
说到原生，大家再熟悉不过了。比如说他们说 IOS，Android 原生界面，意味着界面是他们本来就支持的。而谈到云原生，对于服务而言，他们更多特别强调服务先天具有云上部署、提供服务的能力。这种能力使得服务具有先天的去中心化的能力，先天的横向扩展的能力。这也是微服务重点特别强调的能力。
9.4. DevOps 构架
DevOps 之前，他们也一直在谈敏捷，业界也有战术上的落地方案。比如说极限编程、Scrum 等等。如果说敏捷更多是为了解决需求、产品、研发、测试间的协同、高效，所以 DevOps 更多的是在解决研发、运维间的协同问题。DevOps 近年来发展的是如火如荼，这和领域驱动、微服务构架、云构架技术、虚拟化技术（尤其是 Docker 的发展）的发展息息相关。准确的说，是各式各样技术微妙组合的一种共力。DevOps 的发展，是的运维不再关心应用的部署等问题，那些事情都可以交给研发来处理，运维更多的在给研发提供自动化的构建、集成、部署、监控等等相关的云基础能力。
9.5. 大数据构架
当今的是一个数字化的时代，各行各业都在忙于进行数字化的转型。对于繁杂的销售业务控制系统，数据的价值尤显突出，所以自然对于海量数据的处理、价值的挖掘诉求是必然存在的。所以数据的海量存储、提取、传输、清洗、计算、挖掘等能力就需要通过大数据构架的模式进行结构设计。
10. 总结
现如今，控制系统结构设计的关键已经变成份布式、云化、微服务化、大数据化。构架的本质依然没有改变，而已由于社会的发展，他们的需求，需要处理的问题、依赖越发繁杂，他们需要用发展的眼光，时刻追随技术前沿，进而推进、优化、迭代控制系统的构架结构设计。
繁杂控制系统的构架结构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行繁杂控制系统结构设计时有一定的参考意义。
Rust重写万物？
Windows 11默认文件控制系统将由ReFS取代NTFS
首个中文医学知识LLM：真正的赛华佗—华驼(HuaTuo)
🌟 活动推荐
2023 年 5 月 27-28 日，GOTC 2023 全球开源技术峰会将在上海张 江科学会堂隆重举行。
为期 2 天的开源行业盛会，将以行业展览、主题发言、特别论坛、分论坛、快闪演讲的形式来诠释此次大会主题 ——“Open Source, Into the Future”。 与会者将一起探讨元宇宙、3D 与游戏、eBPF、Web3.0、区块链等热门技术主题，以及 OSPO、汽车应用软件、AIGC、开源教育培训、云原生、信创等热门话题，探讨开源未来，助力开源发展。
TC 2023 详情/报名。
