抽象意味着剥离特性，需要对业务有非常深刻的理解，认知的深度已经触及本质而非停留在表面。譬如关系数据库，就是对一般数据的结构及存储需求的抽象。

上面几楼说的都不是抽象而仅仅是封装。对于我们的业务代码而言，封装的重要性其实远高于抽象。

我是刚升到 11.5 不卡，今天开始卡了。然后升级 11.5.1 又正常了。

便签和便签 App 就是两码事，有把便签往屏幕上面贴的么。。。

貌似没有返回什么结果啊？？？这样开个新的线程慢慢写或者丢进消息队列异步处理就好了，都是立马就能返回成功的。

列表的话，查询的时候注入条件。详情的话，读出数据后代码里面判断。

@hjahgdthab750 不是每个模块一个 git 项目，而是每个服务都是一个独立项目，每个项目都只有一个模块。看起来没什么区别，但实际上两者完全不是一个事。

在 rbac 模型里面，角色的成员其实并不一定非得是用户。你可以把一个用户的集合作为角色的成员。这样这个集合里面所有用户就都间接地获得了角色所授予的权限。

都微服务了，就别再搞多模块项目了吧。有公共依赖，打个包发到 maven 私服上面，pom 引一下就好。

broker,api,consumer 在你的项目里面是不是不同的模块？你把模块改成包试试？

小团队，搞了很多年了。核心其实就一点：自动化部署。至少要实现半自动部署，就是 Jenkins 里面点一下构建就好的这种。至于 CI/CD 搞到什么程度，视你自己的实际需求而定，并非却多越好。

web 从页面发起 ajax 请求的顺序是这样的：
页面 JS->WEB 服务器(Node/Nginx)->后台服务接口

你的域名指向的是 WEB 服务器

主键 id，外键 xx_id

哪怕是低到地板上，无代码，也是有学习门槛和成本的。所以，别把用户定义成任何人就好。

不能简单实现的功能，如果不是需求本身有问题，那么就是设计有问题。这个和产品经理是不是半桶水没啥关系。

分页查询怎么就不能直接查表了？ left join 点赞记录表就好了嘛

首先对需要实现功能进行拆分 /归类，画一个思维导图，在图上进行功能关系、数据流向的推演和调整。一是补足所有功能的依赖，二是使结构合理、稳定、清晰。这样，你就能确保系统的可用性了。不至于在开发过程中再去补，造成系统结构失衡。这个图出来了，其他的就都是水到渠成。

没有学会对问题进行分析和归纳，学多少东西都是白费劲。

都 kotlin 了还要什么自行车。不，用什么 lombok