复杂系统设计解决之道

系统复杂的原因：由大量相互作用的部分组成的系统，组成部分相对简单且没有全局通信，但其相互作用会导致复杂行为。系统复杂通常分为两种：一个是规模复杂，一个是结构复杂，规模复杂相对宏观，结构复杂是规模复杂的一个子领域。在系统设计的时候过度设计和设计不足都会导致系统的复杂度提升。

解决复杂的思路：分治、抽象和标识，分治针对于各个领域的划分，抽象更多的是领域内部的动作，标识用于业务在系统内部的流程。

• 分治：通过系统分治解决系统复杂性，具体的方法就是领域划分（系统划分，模块划分），明确系统的核心能力和边界（战略建模怎么建）

  • 边界：限界上下文，限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。

  • 核心：决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。

  • 通用：通⽤用的归底层，个性的归业务（其他具体的领域）。

  • 耦合：通过划分，就可以减少系统间不必要的耦合。

  • 防腐：系统和系统之间，或者领域和领域之间，通过防腐层进行耦合，这样领域就形成了独立的空间。

  • 建模：领域内建模，领域内建立业务模型，模型是系统的骨骼，支持复杂的业务必须有良好的模型。

    • 数据建模：如实体建模、元数据模型

    • 业务建模：ORM建模和领域战术建模（战术怎么建），前者依然是基于数据库的ER模型。

• 抽象：抽象就是分离变和不变，抽象出来共性的特性进行沉淀作为基础能力，差异性的能力通过配置化的方式进行。

  • 不变：有限度的配置化或者代码实现即可。

  • 变的：对业务模型或者规则进行抽象，然后流程化组合，配置化提效，可视化展示。

    • 分类：功能配置化、数据配置化、流程配置化、界面配置化、角色配置化

    • 方式：自己写代码实现(继承、组合)、配置中心以及Flowable等

  • 复用：归纳定义标准化的协议，流程和模型，新业务复用能力。

  • 扩展：预留「扩展点」支持业务定制/多种实现，两种方式：一种是基于接口的扩展，一种是基于数据配置的扩展。

    • 插件化架构，jar 包级别隔离，同时支持了基于促销类型（策略）的动态路由模式。

    • 领域分层设计，将业务规则分离出来，抽象在领域层，提升系统的可读性、复用性和扩展性。（什么是好的分层）

    • 元数据管理，数据结构进行扩展、部分字段的定义，也包括对应用中的业务对象进行定义、字段设置等功能。

  • 主要的设计模式可以考虑：模版模式，责任链模式和观察者模式。

• 标识：定义统一全局业务身份，贯穿划分的业务领域或者模块，通过唯一的业务身份进行流程进行管理。

  • 定义：作为业务领域内的唯一标识，用于识别业务、管理差异，作为业务领域内的唯一标识，用于识别业务、管理差异

    • appkey，BgBu，业务特征组合

    • 卖家、卖家、商品、门店、品类

    • 订单号等

  • 识别：识别和解析不同的业务身份，然后进行编排和解析到对应的业务能力上。

    • 事件监听器SmartApplicationListener

    • 基于规则自己实现

    • 流程化的编排工具BPM

    • 策略模式

领域相关最大的成本就是学习成本和传承成本，设计了一个很好的架构，但是因为过于复杂，后来维护的同学可能就直接放弃这套规则重新搞了一套，这样也不利于系统的建设。有设计的时候一定要做好code review