前端角度看架构

163 阅读2分钟

reflactor 事件图

现实世界的复杂,混乱,熵增 image.png

1 不循环

2 保持树形? reactor design pattern 从头再来一次

railway-oriented-programming

Maybe Option 事件可以拼装 利用枚举

image.png

image.png

erlang

binary share

image.png

错误处理

image.png

调度

对于循环:函数式语言,尾递归,可以稳定调度

image.png

时间轮

image.png

elixir Phoenix

换句话说,一个公司的技术架构和设计受到该公司的组织架构的影响。同样的,Tyr's law 告诉我们: 一个系统的软件架构和设计和这个系统的目录结构非常相关。

image.png

image.png

看清边界 image.png

other

clean architecture image.png

Event Sourcing CQRS

image.png

image.png

ECS

image.png

image.png

延迟事件,统一批量处理

共性

  • 读写分离
  • 数据/方法隔离
  • 时空分离
  • 同步异步分离 mutaions actions ?

  • 数据聚合成树、群
  • 方法聚合成类型、管道 pipe
  • 抽象、类型聚合

  1. zod 聚合外部对象/json, 完成错误提前校验,拆分小对象
  2. redux/mobx/composition 对应内部状态 DDD,拆分小对象,组合 computed 等
  3. Class 管理各个环境/场景下的方法、操作,作为垃圾箱沉淀逻辑、状态,作为节点,注入/查找切面能力

不能

  1. 独立的 app 划分之后,如何优雅的通信、共享? ddd 无缝接入 react、vue 状态管理?跨框架?
  2. 如何设计(只读?)链表、树结构,方便 tracing/metric/log【内存泄漏】
  3. jenkins, config 下发,depoly dev test 链路,保证简洁性 > 正确性 > 性能
  4. 基于单向生成代码的方式来管理和设计项目
  5. 与后台/node 数据、校验等逻辑同步、同构,开发一次跨端使用【纯胖服务端依赖网络似乎不太流/可行了】【飞书 rust/js sdk 层,胖客户端、瘦服务端?】

resource