扣减做成异步，本身就无法实时同步，肯定会有数据对不上的情况。当你选择异步处理业务的时候肯定做做取舍。
一般这种情况，前端请求服务后直接做加减，障眼法。
要不就是轮询，等待异步业务处理完成

看你的方向啊，只搞后端不需要学习 html+js 。 如果你要搞网站想要漂亮的 UI 那你就得学习 html+css+js 。

java 给 c#擦鞋都不配

游戏开发 技术是最不重要的

说直接用 http code 代替应用返回的状态 肯定又是一堆被 restful 洗脑的教徒

接触更多的业务场景，先写一半能达到 最小可用，然后在优化重构。

linux 桌面系统拿什么和 Windows 比。 讨论 linux 非得黑一下 Windows ？也是够了

正如 11L 说的那样，你这样的封装 没有啥意义。
ORM 可以做到
dbContext.XXXTable.where(x=>x.age>=18 && x.sex =1).group(x=>x.school).sum(x=>x. score)
这样的查询你如何封装呢？按照目前的做法 ，无非就是在 DAO 层 增加一个与之对应的接口。
如果想做到业务查询能映射到数据库或者其他的数据源或者 ORM，你就得引入规约模式，还得需要吧规约转换成其他 library 写法。还得提供每个不同的 library 提供转换 provider 。
既然引入了规约是不是还得包装一个 unit of work
你做到这里时，你回发现你所做的这一切 ORM 都给你实现好了。

要做到业务查询和 ORM 之类的库解耦，这个绝对考验设计能力，绝对不是你这样简单的封装就解决的问题

几千个用户 用啥设计啊 数据库 order by

下单减库存 和支付减库存做成配置项就可以了。减库存这个也不是啥难点吧。。。。

业务代码很难进行单元测试的。
数据库没法进行测试,引入 InMemory DB 对数据库达不到测试的要求。
如果要介入数据库还得写插入和清库的代码。
第三方依赖也是一个问题。
到最后你会发现，写业务代码一个小时，单元测试得写上一天

@waibunleung 这样的封装 会导致失去 ORM 很多的特性,而且会导致 DAO 层越来越臃肿 出现很多 FindByXX 之类的 func

ORM 和 DAO 是不冲突的。Repository 和 DAO 不是一个概念 。
DAO 是单纯的对数据库进行增删改查的一些操作和特殊的业务逻辑。
一个好的 ORM 基本就代替了 DAO 层 90%的作用。可以看看 DotNet EntityFramework Core ORM 基本没有比他还好用的
如果你的项目涉及到多种数据源需要提供给 Service 这里可以引入 Repository 的概念
使用了 ORM 也没有必要在对 ORM 进行一层封装，这种封装我认为是脱裤子放屁。

楼主的思维方式和性格 和当年 20 岁一样，有一种莫名的优越。太局限于技术上的思考。

大连也能开到 20K-30K 的薪资啊。不过你这学历是硬伤找不到 高工资的工作的。

高质量的博客是不会搞这种的，都是那些垃圾 copy 文

虽然你配置了跨域，但是接口报错或者其他问题导致不通前端就会提示跨域错误。

目前公链的项目不发行 Token 。没人会去关注他，也就慢慢的死了。只要有激励就有人炒币。什么时候区块链能不和货币挂钩再说吧

可视化页面编辑
3D 动画场景
音视频