来，写一些常用的架构模式。

居然要说对系统架构的理解，那需要先说明一下，对系统的理解，在此基础上才能进一步将系统及业务域进行整合及交互，然后结合不同层次构建整个系统架构

对系统的理解

系统中最重要的两个概念：实体和行为

形式：描述系统是什么

行为：要做哪些事，行为会产生一个后果，这个后果的承接方就是实体

实体：承载着该系统或业务域的相关表述的对象

  • 关系：实体之间存在功能关系（动态）和形式关系（静态），功能关系可以理解为一些行为交互，形式关系可以理解为聚合，包含等关系
  • 边界：实体是属于某个业务域的，拥有不同的业务域这个上下文，才能进一步明确它的价值和作用

抽象：抽离于实体的性质描述，只含本质而不含细节，是我们对系统众多实体更深一步理解的重要手段

对系统架构的理解

我理解系统架构就是在系统的实体和行为基础上，结合着技术层面做的一些解析和交互方式的改造，例如（以下列出来的不一定是真正的系统架构）：

CQRS

  • 改变实体的状态的行为和实体状态的查询实现分离，关注点是针对实体聚合关系的实现方式；

事件总线/事件驱动

提前将事件与处理器绑定，在Spring框架中就有事件通知机制，在redis中就是基于reactor的事件驱动，之前做过一个ddd项目也借鉴一些事件总线的机制；例如，一个订单已创建的事件，针对事件总线形式下：相当于一个实体状态发生变更后，将通过哪些行为进一步影响其他实体的状态；事件驱动更多的是将行为绑定一个处理器将行为与实体解耦。

微内核

通过核心程序完成最小mvp或主题流程和框架的搭建，然后通过插件或者扩展点的形式集成或引用，实现行为的扩展，通过微内核的模式可以隔离个性化功能，将主体业务与扩展点隔离和治理；例如我们最近做的一个项目，通过流程编排的方式构建主题业务流程，针对不同前台的个性化需求通过spi，jar，rpc来完成扩展点的植入。

待续。。。