@omniversia DDD，整洁的架构也是业务长期维护需要看的书籍

@fenguxnyu 这两个接口是否只是查询？

用各种代码写界面 dsl，最后又用代码来生成 dsl 的配置，为啥要花那么多文字来描述，从之前到现在，为了偷懒，程序员啥事没做过？

不是这样倒是出了鬼，一些古传代码估计有一二十年还不重写重构，指着现在的外面架构的简洁骂之前代码流程垃圾的玩法，真心猪狗。

上全流程 metric，查看一下是哪里慢了，现在这描述不清楚是数据库慢，还是 Hibernate 慢，还是代码慢。

缺点：
1.纯函数式难以利用之前几十年大部分积累的面向对象的软件工程实践。
2. 纯函数式比较适合数据处理，不适合复杂业务建模。
优点：
1.合理规划之后的纯函数式可以无缝由 iaas----paas---saas- serverless
2.并发比较容易实现。
人员 ide 缺点：
1.fp 的算法和面向对象的根本不一样，有大量的转换培养成本。
2.fp 的基础设施问题，现在支持 fp 的基础设施少得不行，基本都得借助 MQ 来解耦传统设施对于函数式架构的污染。
3.fp 的优化，debug 等等，友好的 ide 比较少。

onenote 的格式上的强大，现在木有竞争对手。

如果是强业务类型，不要虚伪的微服务，还是 DDD 好好研究一下； 如果是纯数据的，倒是可以研究 functional programming

function 计算的核心点是单个 service 最好是业务自包含的（最多再加一点外部调用，支付，存储，exc ），否则就会变成基于消息队列的 function 风暴。

cncf 用 grpc 的原因还用说么，k8s 等基础设施是抄谁的？ 并且当时没有造足够多的 rpc，大家也不知道如何设计一个通用性能高而且和传输协议解耦合的传输层 rpc，gprc 好歹是当时的唯二中的一个半自动化 rpc，比 facebook 的 thrift 友好一点，

现在更合适的通用连接方式 rsocket 基本会成为后续更主流的方式，协议层和传输层解耦合，协议和应用捆死的模型最大规模的应用不是 servlet 么，吹了那么多，servlet 啥时候换 http2 协议性能提升了不少了？

最简单的 apm 用啥，API gateway 等最基础的服务治理有几个支持了，支持程度如何？

@itstudying 我的意思是边界约定好，大公司使用一部分特殊能性能的工具是他们能配套建立全链路的工具，小公司一般没有，而这种全链路的工具没听说过哪家开源的。rest 是因为文本的自然原因导致容易找到全链路的替代品。

Java 有类型推断或者模式匹配么？ 没有… 还是找个看不到的吧。

这种得开发配套的工具链，否则出问题联调，apm 接入，debug 等等一堆的工具链需要开发配套，如过涉及到 cdn，网络硬件等更深远的坑，就等着哭吧。restful with http 主要是生态，别的东西有个 JB 生态

爬虫能把对方站都爬回来？ 下次可以不可以爬一个 google 回来？ 在线等

啥引擎，mysql 有好几个引擎呢。

typescript 的类型系统，每次用 kotlin/Java 都想说我叉，scala 的 dotty 到底啥时候 release，c#啥时候有成熟的大规模中间层推广一下。 面向对象的时候才真正学会了啥叫数据表驱动编程，上帝之手打你儿子的 mvc 编程啥时候终结啊。

跑 CI/CD，只要项目内部统一，这部分脏活可以用脚本自动化解决。