DDD 用在前端是为了什么

从 2020 年开始思考一个问题:如何让代码更好维护?

当时想到的是顶点控制 + 模块化。所以采取的方案是:所有状态逻辑都由 Vuex 控制,Vue 只有 UI 逻辑与 UI 本身,只需要关心 Vuex 的模块在何时加卸载即可。而这个思路在当时有一个很好的选择:dva.js

从 2021 年开始因为产品经理能力滂臭,以致更新问题:如何尽量让一套业务代码到处可跑。因为这个时候的产品只有三个关键词:短时间、业务趋同、不同的产品UX。采取的方案是:在将 UI 和逻辑分开基础上,对代码分层。逻辑代码都是无依赖 TypeScript,利用 React Hooks 封装调用,依赖倒置

这个做法确实保持了一定时间的血压下降,这也给滂臭产品一个得寸进尺的机会 —— 1.5 人月干了四个项目(真是TMD)。好在时间几乎都花在 UI,程序都用 React,小程序也用 Taro3,所以似乎问题不大

但是 2022 年又把血压抬到原点,这下不得不重新思考这个问题

相关阅读:

把 .NET 搞到 CFWorker

早在 .NET 6 时期发布 MAUI 时就已经对 C# 非常感兴趣,加上这几年对游戏开发的学习使得我重新关注这款语言平台

关联阅读:

如今 .NET 8 新增了各种能力:例如进一步对 wasm 的支持(Blazor 美如画),还有 NativeAOT。再加上微软自从改变了路线开始尊重开源社区,并且先进技术跟得一次比一次快,让我又当场狗叫

「.NET is THE NEXT GENERATION」

总所周知 CloudFlare Workers 本来是一个服务托管平台,还是跟上一篇讲得差不多:它优先托管基于 NodeJS 的应用或者 FaaS。但是!它确实也进入了 WASI 的实验性支持

所以当我单方面狗叫「WebAssembly is FUTURE」之时,我已经在想:用 C# 狸猫换太子是不是有戏?

醉翁之意不在酒啊

「试试 WasmEdge」(迟到版)

22 年我在找一个开源的可以直接部署的 Serverless(FaaS) 方案。短时间尝试了 OpenFaaS 和 Knative,但这两个分别都有某些地方并不符合当时的需求

接着发现了 WasmEdge,这是一个利用 wasm/wasi 的运行时,支持被嵌入式执行

当我看到它第一眼,加上原本我对 WebAssembly 的理解,我直接在站起来单方面宣布:

WebAssembly is FUTURE

启动画面!更新!

上一次更新主页已经是 21 年了

每次都觉得 Riot Games 在潮流设计这部分一直走在前列,例如早在 kda 发布《MORE》的时候开始使用镭射渐变,依稀是来年季中赛还是世界赛开始使用粗犷主义(brutalism),直到现在看 valorant 都是。结果粗犷主义在 23 年才逐渐渗入更多的范围,变得比较容易能看到

(但是国内的平面设计还在明度渐变字……唉……「程序员」和「设计师」)

这一年多以来都一直在计划和修改我的主页风格设想,去年就想整体跟随博客都迁移到 brutalism。终于迟来一年,修改了启动画面

splashscreen-2

顺便支持了之前没有支持的移动端响应式。只能说这个 23 年过得差点让我失去道心

「成为玩家」2023

回顾整年,我在犹豫和怀疑是否还能称为「成为玩家」—— 似乎一整年都跟游戏没什么关系,我也没有相对应的付出

好巧不巧,写文章前闪念到岩田聪 GDC2005 年那场分享《Heart of a Gamer》,让我想起来一些东西

游戏的存在只是为了一个意义,那就是快乐,给所有人带来快乐。 —— 岩田聪

回想今年的经历,至少可以拟合成一条斜率在 (0, 1) 的斜线。所以先暂时给标题加上引号,因为我可能需要有一些证明

关于「有效加速主义」

我确实是「前端已死派」。不过是片面已死,而且死得好

我觉得经历过前几年的互联网都应该知道,市场对于「前端」的需求是有点畸形的。大量的电商微商,无论是各行各业都在追求「数字化」而制造出很多所谓「ToB产品」,再接着是很多公司「嗅」到一种莫名的商机,开始制造这些价值很低的「ToB产品」并进行 SaaS 化、PaaS 化……大批量的为了以此赚快钱的外包……这制造了一个非常务虚的市场,使得这几年前端环境都很乱,大批量没有任何软件知识的人通过一些非常荒谬的培训之后开始自诩「程序员」上岗……这其中还不包括就是看中程序员工资高但本身毫无追求的「冒充程序员」

所以当经济支持不了这样的市场之后,大规模的裁员变得显而易见,许多公司所谓的「大前端」开始分解

所以我说的前端已死,指的是这些毫无意义,不学无术,能轻易替换的前端。因为他们只是在使用 Ant DesignElement-UI 进行无意义的拼凑而已

甚至 Levy 曾经跟我分享:

我认识一个前端说:前端不需要懂业务也能做

关于部分会换到另一篇进行更细致的讨论,把它带出来只是想说明我时刻都在自我怀疑和开始不解。没有人对「科技向善」有感,没有人对「技术发展」有感,没有人对「WebNN」、「WebAssembly / WebGPU」有感。我有时会听到别人问我,用 rust / elixir 能不能赚钱,甚至我见过太多人打开 ChatGPT,在输入框输入「如何利用xx赚钱」甚至是「有什么办法让我有钱」……

直到我遇到了「有效加速主义」

用 rust 实现 i18n converter

软件国际化必然需要翻译文件。虽然我也很想用类似 locize.com 之类的服务管理翻译,这样 i18next-locize-backend 直接游戏结束

可惜用不得,只有一个甚至早期管理还很乱的 excel 文件,所以需要解决「如何把它变成 json」的问题

TL;DR

  • 插件类型应用必然使用抽象工厂,早在设计 FEMessage/upload-to-ali 服务端就这么用
  • 将文件对应为统一结构,以扩展的形式输出对应要求格式文件
  • 使用 calamine 解析 xls(x) 文件
  • 使用 rayon 直接让列表多线程

我必须立刻在 Tauri 跑 WebRTC

按照需求,本来实现 WebSocket 的目的是收发 Banshee 的消息(主要是收)

后面突然灵光一闪:上个 WebRTC 怎么样?于是开始一段「为了醋包饺子」的心路历程:

  1. 虽说原本是为了本地调试,但这套技术很明显内网都能用
  2. 如果有一个「授权」对话,那么就可以在内部进行「远程问诊」
  3. 测试或者验收遇到什么问题,望闻问切的第一步是
  4. Remote Display / Remote Desktop

TL;DR

  • 调整 WebSocket 支持的实现
  • 实现信令服务器部分
  • 因为流量都在内网,所以不需要转发(STUN)

我必须立刻在 Tauri 跑 WS

其实开发一个程序思路一直都是一致的,并不会因为是前端就会差/简单多少。再加上之前因为有「多端」这个「产品概念」之后,所以程序上一直在解决一个问题:如何将 Web 之外的逻辑固定下来?于是有了 Banshee,下次细说

既然有一个框架了,并且也选择使用跟 Angular 类似的 root 级 DI 这种路线之后,开始有一个想法:

流向很清晰,这个时候有一个测试监控一体机是不是实现方便作用不小?

于是有了 Banshee Cockpit,但它也跟 Banshee 一样,下次细说

又到了技术选型环节:早在三年前就尝试的 electron 方案 electron-react-koa-template(已归档),当时是为了直接在树莓派运行智能闹钟程序时顺便提供 API 以远程操控,所以让 electron 附带的 node 跑起来一个 koa

でも、选型依然是我目前的经典搭配:Tauri + Solid。那首先要解决的有两个问题:

  1. 还是一样,需要跑一个 server
  2. 因为需要收发 Banshee 的信息,所以需要 WebSocket

TL;DR

  • 你可以直接用 Rust 提供的基础库,但我用 axum
  • 集成起来很方便,麻烦的是 Rust
  • 摆烂了,Rust对于内存的执着有种让人想一拳打爆屏幕的冲动

0%