架构编排的内核公式：架构元素+架构规则

类比[[社会组织的内核公式，及时间/空间两种通用规则|社会组织=社会实体+社会规则]]，架构编排的内核可以概括为：架构编排=架构元素（或实体）+架构规则。这个公式解释了为什么微服务、DDD、PaaS这些看起来毫不相干的架构知识可以被归入同一个概念下——它们都可以用”元素+规则”这个二元组去拆解和分析。架构元素随时间演进不断丰富：语言形态上经历了面向过程、面向对象、面向函数；服务形态上经历了单体→SOA→微服务；平台上出现了IaaS/PaaS/SaaS/中台；模型上从DFD、用例图、类图、时序图，扩展到业务架构里的价值链、价值流、服务蓝图；元素的规模也在不断膨胀——单体架构时代整个系统能打包进一个文件部署，到了微服务时代一个复杂系统所需的微服务元素数量可能高达成千上万个。架构规则负责把元素有序融合在一起，可以用两个具体案例说明规则本身的演变：SOA和微服务都有”服务”这个概念，但SOA对服务间通信协议做了明确约束（单一性原则），微服务则出于灵活性和可扩展性考虑放开了这种约束——正是这种交互规则的”多样性”支撑了复杂系统的规模性增长，而非SOA式的单一性原则；面向过程编程的元素是过程（函数），元素间规则简单，就是调用或反调用，而面向对象编程的元素是对象，对象间的规则复杂得多，包括依赖、关联、继承、聚合、组合。规则同样存在时间规则（RUP的四阶段、DDD的战略/战术设计、TOGAF的ADM方法都按时间串联；敏捷方法本质是改变了开发方式的时间规则）与空间规则（物理部署图里元素分散在不同城市/园区/网络区域；应用架构的分层、DDD里领域/子领域/限界上下文/聚合的分层，都是空间层次规则）两种通用形式。可迁移启发：面对一个陌生的架构概念时，先问它的”元素”和”规则”分别是什么，往往比死记硬背这个概念的定义更快建立理解。

结构图：

flowchart TB
  A["架构编排=架构元素+架构规则"]
  A --> E["元素随时间演进不断丰富<br/>(面向过程→面向对象→面向函数<br/>单体→SOA→微服务)"]
  A --> R["规则"]
  R --> C1["具体规则案例:<br/>SOA约束通信协议(单一性) vs 微服务放开约束(多样性)"]
  R --> C2["具体规则案例:<br/>面向过程=调用/反调用 vs 面向对象=依赖/关联/继承/聚合"]
  R --> C3["时间规则(RUP/DDD/TOGAF按阶段串联)"]
  R --> C4["空间规则(部署图拓扑/应用架构分层)"]