业务架构的评价标准看三个指标。第一，自主性，需求实现过程中需要多少沟通。第二，一致性，圈定的必须保持一致的实现多大程度可以被保持。第三，反馈速度，最终的业务效果，技术故障，多快可以反馈到对应的负责团队。

https://github.com/krareT/trkdb 就是这样的, 相当于压缩

原因主要是生态，一门语言不仅仅是语言，还包括上面的库。除非有非常强大的投入，要完全造一套库出来，成本太高了。所以大部分小众新语言都是采取借别人的生态的做法，比如编译到 JVM 上执行。

运行时和语法是不能割裂的，很多语法需要独特的运行时支持。比如 golang 要求每个函数都可以是 coroutine，那么就可能导致复用 c 的函数库变得困难。这也就导致了，寄人篱下，必须低头。这就导致了新语言的语法特性是受限制的。

如果要换组，或者换工作，别人为什么要你? 照着这个目标努力积攒自己的跳槽资本吧。今天的工作做不好，明天的工作也找不到好的。

把样板代码提取成代码生成器，用 JSON 文件配置给代码生成器做参数。如果参数太多了，就果断回退回纯手写。不要试图写过分通用的生成器，在你有限的几个项目里能够复用得到收益就好了。

面向对象的目的是为了依赖倒置，依赖倒置就是 a 做为底层模块，被 b 和 c 所依赖。这样做的好处是 b 和 c 中的实现细节，a 是完全引用不到的。这样就可以避免写 a 的时候做过多的假设，导致代码纠缠在了一起。b 和 c 之间没有直接引用关系，b 的作者就可以不用知道 c 的作者在搞什么幺蛾子。这样大家的知识边界就清楚了。

面向对象实际上是利用运行时组装来实现依赖倒置。如果你有编译期组装的方案，也可以实现同样的依赖倒置的效果，不一定需要运行时组装。

可以参考一下 https://github.com/taowen/modularization-examples

业务数据就代表了“业务流程”的当前状态。强行“解耦”又是何必呢。不如把业务数据进行规范化，称为 single source of truth.

@Mohanson https://github.com/mohanson/doa 唯一正解

@est 怀念 delphi

这么多年都没有放弃 python，支持一下~

跨洋上线啊：）

https://overreacted.io/the-elements-of-ui-engineering/ The Elements of UI Engineering
https://zhuanlan.zhihu.com/p/53832406

组装的难度在于切分模块。切分得太碎了，模块之间就会有很多的互动，从而丧失切分模块的目标

* 你无法独立理解每个模块。因为模块组装起来会的行为，不是每个单个模块行为的简单加和
* 你无法在多个项目之间对模块进行独立复用，因为任何一个模块都会牵扯出一大堆关联的模块

我举了很多具体的业务场景来说明这样的困境 https://github.com/taowen/modularization-examples

每个大厂都有 10 个这样的内部项目 https://github.com/taowen/awesome-lowcode

竟然看到了南昌的职位，不容易啊