我们经常提到复杂系统，那么复杂系统到底是什么？我们看一下Wiki的定义：复杂系统（英文：complex system），也称为复合系统，是指由许多可能相互作用的组件组成的系统。强调两点：
由点
点与点之间有各种联系
这两点的规模和复杂程度直接决定了系统的复杂程度。比如说，以我们的电子商务系统为例。它分为很多部分，包括商品、库存、采购、订单、物流、财务。这只是一个广泛的分类。 C端还有营销、会员、采购、售后等系统，B端有系统。商户结算、管理等系统。各个部分和系统之间有着千丝万缕的联系，使其成为一个复杂的系统。当然，还有更多。随着业务复杂度不断增加，整个系统的复杂度也会越来越复杂。
生活中，我们经常谈论“建筑”，那么“建筑”到底是什么？ Robert C.Martin《架构整洁之道》中的定义：软件架构是指设计软件的人赋予软件的形状。 ，这个形状是指系统如何划分为组件（Component）、组件如何排列（Arrangement）、组件如何通信（Communication）。维基百科的定义：对软件整体结构和组件的抽象描述，用来指导大型软件系统各方面的设计，IEEE的定义：架构=组件单元的结构+组件单元的关系+原则和指南。总的来说，会包含几个内容：
整体：强调零件的组成，强调合力
规则：强调各部分之间存在关系、规则和约束
对应：强调各部分之间存在对应和相互作用
这样说，我们人类社会本身就是一个社会结构，有各种责任、分工、圈子。就我们软件系统而言，DDD是一种架构，MVC也是一种架构，大数据设计也有大数据架构。所以，建筑无处不在，好的建筑能够规范和指导特定问题、特定领域。
我们知道建筑这个词来自建筑行业。英文原文是：Architecture。维基百科上的解释是规划、设计和建造建筑的过程和产物。那我们就用建筑行业来了解一下吧。盖房子大家都很熟悉了，我们盖一栋平层小楼、两层小高层、五层小高层、十层摩天大楼、百层摩天大楼。风险完全不同。建造摩天大楼需要更高的成本，过程中的不确定性更多，挑战和风险更大，比如如何选址、选择什么样的结构、如何承受荷载、如何控制照明、如何优化、如何热量，如何供水、排水，如何通风，如何避震等等，这些考虑得越多，房子未来的质量和可控性就越好。
所以架构本质上是一个指导性约束，约定整体与部分、部分与部分之间的关系，从而使整体更加稳定可靠。
我们上面举的例子可以称为建筑架构。其实架构有很多种类型，比如业务架构、应用架构、技术架构、数据架构等等，单一的架构分类从不同的维度会有不同的看法，复杂程度也会有较大差异。例如，企业级架构可以突出公司的整体战略、业务参与、分布和努力。单个业务线也有自己的业务架构，突出自己的业务目标、战略等，应用架构、技术架构也是如此。将会有具有不同层次愿景的架构。我们从业务线内部的角度来简单解释一下我们常见的架构分离。
说到业务架构，就是顶层设计。业务的界定和分工甚至会影响整个公司整体组织架构的建立和关系。业务架构重点关注业务领域划分、模型设计、整体业务的语言转换、内化为领域通用语言。
反映了应用程序内的结构关系。一个应用是如何设计的，包括如何划分模块、如何实现功能、如何支撑技术、如何展示数据、如何定义流程、如何实现逻辑、如何存储数据等，都在范围之内应用程序架构。我们常说的MVC、分层架构、CQRS、DDD传统洋葱圈架构、DDD六边形架构等都可以归于应用架构的范畴。
技术架构不一定局限于单一应用，尤其是在当前微服务架构时代，服务如何交互、服务如何治理、数据如何存储、缓存如何构建等等，都是架构的技术范围。技术架构为应用和业务架构提供了技术基础，以实现更好的业务发展和更稳健的迭代和发展。
无论是什么架构，我们首先考虑的一定是满足我们实际的业务需求。没有需求的架构就相当于空中楼阁，毫无用处，不切实际。这不是真正的建筑。一般来说，功能需求将直接决定业务架构，对应用和技术架构影响不大。我们的架构必须能够正确、完整地支持功能需求。
架构满足功能需求是首要任务。同时，我们需要考虑稳定可靠的支持功能，这意味着我们还需要满足一些非功能性的需求，比如性能、可靠性、可扩展性、兼容性等。
为了更好的服务功能，我们需要保证架构能够稳定高效的运行。不会出现服务偶尔崩溃或不可用的情况。
同样，服务必须始终对外界可用。即使单个服务实例出现问题，我们仍然可以正常向外界提供服务。
功能要求不是静态的。尤其是在当今敏捷时代，需求并不是一下子就提出来的。我们需要对系统和服务的整体能力有一个全面的定位和掌控。这就要求我们的架构能够在新需求出现时轻松扩展支持。
一个好的架构必须方便操作、管理和监控。即使从微观层面到工程管理，代码也必须易于维护、扩展和协作。
一般功能需求都会对性能有一定的期望。这个业务需要我们在架构上做很多工作，比如读写分离、缓存、异步干预等，以满足整体架构的响应能力。
有些同学存在误解。当他们想到这样一个系统的时候，他们就觉得会很复杂，就会考虑退出。但你认为难的事，并不一定是难的。我们都知道那句老话：“不知者难，知者不难”。往往由于经历的不同，每个人对同一个问题会有不同的想法和想法。这就是为什么我们在设计系统时强调专家的重要性。尤其是DDD领域驱动设计方法的逐渐被提及和广泛应用，进一步提升了领域专家的重要性。只有这样，我们才能识别现实问题的复杂性和根本痛点，进而客观合理地得出可靠、恰当的解决方案。显然，复杂系统设计中有两个非常重要的环节：需求分析和架构设计。
在需求分析过程中，我们需要确认需求要解决什么问题，它的作用是什么。现在最流行的分析方法是DDD领域驱动分析方法。使用DDD模型分析业务需求大概有几个步骤：
确认角色
确认角色功能
确认问题子域
确认型号、事件、归属
确认有界上下文
找出核心问题。到了接受需求的时候，有些人会直接进入开发设计阶段，尤其是职场人士。其实，当我们遇到需求时，我们需要更多地思考为什么需要这样做。明白了这一点，对于我们进行业务等相关架构设计，然后对整个需求进行引导，才不会轻易误入歧途。
复杂问题简单化，需要将复杂问题分解成小模块，一一解决。各个模块的职责会相对单一，未来的扩展性和可维护性也会相对独立和简单。
确保使用通用语言进行沟通，尤其是在面向领域的设计中。每个人都必须对领域模型有一致的理解。
明确系统和模型的定位、关系、交互等。
具备未来规划能力，包括系统、技术、解决方案、能力等，使系统能够长期提供更好、更稳定的价值服务。
遵循各种设计模式、最佳实践，避免从0开始，包括：SOLID设计原则、CAP理论、BASE理论。
复杂的系统必须划分为详细的功能、模块和领域。每个模块都应该有一个明确的、单一的职责。这样，我们在分析问题的时候，就可以将问题集中在一定的范围内，而不会产生太大的影响，这样就方便了整个系统的维护和扩展。
当我们做小功能的时候，我们可能不会想太多。但当涉及到复杂的系统时，我们要考虑的因素很多，包括未来的功能承载、流量承载、数据规模、响应需求等等，这些都要求我们在纵向或横向上留有足够的扩展能力。这些不可能一蹴而就，而是需要进行规划，以便进行必要的扩展，使系统具有长期价值。
对于复杂的系统来说，已经不是一张或者几张流程图就能解决的事情了。我们需要通过领域架构明确领域划分和领域边界，通过系统架构明确功能模块和功能边界，通过应用架构明确各个应用的职责、边界、结构划分、依赖关系等。通过技术架构，我们明确了我们所使用的技术栈以及整个系统中的应用边界。通过数据架构，明确我们的数据存储方式、结构、数据用途等。
这些结构必须清晰具体，注重系统的长期价值。
对于复杂的系统来说，分裂是不可避免的。大问题被分解为小问题。基于领域、模块、功能的划分，将问题划分到不同的边界，一一攻克。如果小问题能够得到妥善解决，那么通过合理的依赖和组合，就能有效解决大问题，达到构建整个系统的目的。
随着社会的不断进步，信息成分的发展，我们需要更多的信息手段来解决系统性问题。之前我们用的更多的是数据驱动的模型，也就是我们首先会想用什么样的结构来存储相关的数据，模型之间有什么样的依赖关系，如何组织数据，如何组织模型。数据。数据和外设交互，这些思想也是典型的MVC架构。
MVC架构迫使我们朝着视图方向发展。我们知道，观点的改变是最不可控的。越是面向用户的东西，就越容易受到用户的主观影响。我们知道，复杂的系统不可避免地具有复杂的依赖关系。依赖关系不能存在于视图部分，但肯定会显示为接口依赖关系。对于复杂的系统，必须迫使我们改变思维，迫使我们针对界面进行设计。结合业务系统的复杂性，如果想让系统在未来具有长期价值，就必须将大系统进行拆分，用统一的业务语言进行描述，将无法识别的问题拆分为可识别的问题域。解决方案，这就是现在逐渐流行的领域驱动设计方法。
领域驱动设计迫使我们不再由数据驱动，而是由领域驱动。遇到问题，我们就对高级领域进行划分、拆解。这个问题属于哪个问题域，或者需要分解到哪些问题域，然后通过域和依赖关系的组合来解决最终的问题。
领域驱动，早在2004年，Eric Evans就在《Domain-Driven Design : Tackling Complexity in the Heart of Software》（领域驱动设计：如何处理软件的核心复杂性）一书中对策略和战术进行了阐述。
目前，对于复杂系统的设计，领域驱动模型有利于系统的可持续发展。
事实上，微服务架构是早期SOA（面向服务的架构）的变体。事实上，这个术语从Martin Fowler在2014年发表的一篇文章开始在业界流行起来《Are Microservices the Future》。微服务架构强调去中心化管理，尽可能保持服务的自治性和独立性。重点是通过不同的小型服务来集成和获取能力。这样我们就可以有选择地纵向和横向扩展服务，同时也避免了单个系统的臃肿和功能的堆叠和耦合。
说起native，大家都不陌生。例如，当我们谈论IOS和Android原生接口时，意味着该接口是它们原生支持的。说到云原生，对于服务来说，我们更多强调的是服务具有在云上部署、提供服务的内在能力。这种能力使得服务具有先天的去中心化能力和先天的横向扩展能力。这也是微服务所强调的能力。
DevOps 之前我们一直在讲敏捷，业界也有战术实施方案。比如极限编程、Scrum等。如果说敏捷更多的是解决需求、产品、研发、测试之间的协作和效率，那么DevOps更多的是解决研发和运维之间的协作问题。 DevOps 近年来发展迅速，这与领域驱动、微服务架构、云架构技术、虚拟化技术的发展（尤其是Docker）密切相关。准确地说，它是各种技术微妙结合的共同力量。 DevOps的发展意味着运维不再关心应用部署等问题。这些事情可以留给研发部门。运维更多的是为研发提供自动化构建、集成、部署、监控等相关云服务。基本能力。
当今是数字时代，各行各业都在忙着进行数字化转型。对于复杂的业务系统来说，数据的价值尤为突出，自然存在着处理海量数据、挖掘价值的必然需求。那么海量数据的存储、提取、传输、清洗、计算、挖掘等能力就需要通过大数据架构模型来设计。
如今，系统设计的关键已经变成分布式、云化、微服务和大数据。建筑的本质没有改变，只是由于社会的发展，我们的需求、需要处理的问题、依赖关系变得越来越复杂。我们需要用发展的视角，始终紧跟技术前沿，进而推动、优化、迭代系统的架构设计。 。
复杂系统的架构设计不是一朝一夕就能完成的，只有合适的才是合适的。希望这篇文章能够对你在设计复杂系统时有一定的参考意义。
打造高质量的技术交流社区。欢迎从事编程开发、技术招聘的HR人员加入。也欢迎大家分享自己公司的内部推荐信息，互相帮助，共同进步！
