你又要深度，又连官方手册都不愿意坑，什么有深度的技术资料是长度很短的？官方手册真的是最好的资料

早说过，命是自己的，钱是老板的。前几天还在 V2EX 看到有人说自己经常 996 并以 996 为自豪，我只想说，失去健康的时候，希望不要后悔

朝九晚五一点都不上，只要愿意接受工资降级，你能找到一大批，资本家都聪明的很

楼主你真敢租房贷款啊，不怕个人信用完蛋？

@passerbytiny
“在 DDD 模式中，Repository 提供两个检索方法，领域服务或者应用服务决定调用哪个方法。”
我看完了你的描述，但是我这里的需求是：领域服务希望 Repository 的方法能更灵活一点，因为在我的应用场景里 Repository 对应的是持久层关系数据库的访问，对一张表(对象)只提供一个方法就能完成大部分查询，是件很有用的特性。如果 Repository 必须用多个方法才能应对领域服务的需求，这会增加额外的开发成本

@passerbytiny
好吧，严谨一点说，spring data jpa 用 repository 来承担了 dao(或者叫 mapper)层的功能

我没看懂“不应该考虑表、字段等任何数据库方便的概念”这句话，你不从数据出发如何建模呢？或者说你觉得正确的思考方式是什么样的呢？

我第二段的需求，是希望能追求灵活性，举个例子，User 对象(表)，在场景 1 下需要搜索 userName 字段，到场景 B 需要检索 nickName 字段，按照 spring data jpa 的文档，正统的做法你得在 UserRepository 准备两个 find 方法
findByUserName(String userName)
findByNickName(String nickName)

这在我看来是比较麻烦的，因为很多其他 Orm 工具提交这样的做法,以下是伪代码：
DYSQL dySQL = new DYSQL() //动态 sql 条件查询类生成
dySQL.eq("列名"，列值)..eq("列名"，列值).groupy("XXXX").Order("XXX");
select(dySQL);
嗯，其实就是上面提到的 QueryDSL

@CtrlSpace 人的追求是无止境的，你用过 mybatis-plus 就明白了，如果你用过一些动态语言的 ORM 工具比如 ruby 的，你更会明白 java 的这些 ORM 工具局限在哪里

@richard1122 首先谢谢，其次这个实现的还是过于简单。它只能附加字段条件，对注入 limit，group，order 就无能为力，而且无法嵌套，不过你这个提醒了我，我发现我文档看的不仔细，这部分文档上有，但是我看漏了

@qinxi 感谢，我在文档上找到这两个了，QueryDSL 比较理想。但是 JpaSpecificationExecutor。。。怎么会有搞的如此复杂的实现？它有没有什么特长？比如 QueryDSL 做不了它能做的事情？光看功能他做的事情和 QueryDSL 差不多，但是 QueryDSL 比它直观和简单的多了


@letitbesqzr 请教有啥是 QueryDSL 实现不了的？现在选型比较关注框架的弱点方面

@Chan6 喜欢国家所以移民？那你会被现实无情的打脸到由爱生恨，不以利益为驱动力的行为最终会败给现实，祝你能永远喜欢下去，不用回我，我不会再回复

@jerrry 强在哪里？请问移民的目的是什么？不就是想要更好的生活吗？去一个经济已经衰退了 30 年，财政都快崩了的，只不过维持面子上的“发达国家”，图啥？脑袋进水了吗？想求财应该呆在上升型国家，想养老去北美北欧。移民日本的目在哪里？搞清楚自己的利益所在点很难吗？

@frqk 我说，你一定不知道日本搞了快 20 年快乐教育，发现是扯淡，现在回头重新搞 80 年代填鸭教育的那套吧，谈私立教育的话日本还真有厉害的，公立教育。嗯，呵呵

@Chan6 我只提醒你一句，现在移民日本等于 49 年加入国民党，你移哪里不好，选日本。你不知道日本已经衰退 30 年，内部少子化问题一箩筐吗

@freak118
吃过的憋够多自然就会变成过来人，吃过的憋够多也不意味着成为过来人后就一定幸福，这是忠告，人生充满不如意

作为过来人，我认真的和楼主讲，这类活动大部分时候就是吃吃喝喝玩玩结束，真能找到另外一半的几率极低，其实很多人心知肚明这一点，所以你也别怪大部分男人懒得参与这类活动。而女方大部分抱的心态是想捡漏或者干脆就是来玩玩，所以女方参与这类活动的人反而比男方多。但是我要说的就些女的的内心指标都订的很高的，招惹她们是自找没趣

@nyse 性能问题就在于 web 前端比不上 native 啊，就算不上框架也一样比不上。否则干嘛要折腾 webassembly。我当然知道后端只发 json 给前端是优秀的开发模式，其实这套模式在 native app 上已经被验证过，WPF，android UI，都走的这条路。没道理 web ui 不走。所以我才说，核心问题就是性能，性能补上的话 native app 就要被踢进历史的垃圾堆。现在的问题是性能跟不上，但是 web 前端开发界目前过于讨好开发者，开发者在风口上也是比较忘乎所以，张口闭口只谈技术先进，开发模式现代，而用户体验在落后的性能下表现不佳的问题，没有人关心，相反，像 qq 邮箱，百度首页这样就算要用落后的技术也要保证用户体验，在这个时期，真的算的上清流了

早睡早起，吃好休息好，这才是核心，天天加班别谈养生，先考虑换工作比较好

后端渲染比前端渲染速度快，这不早就说过吗，如果前端渲染性能没问题的话 native app 早就要被干掉了，2018 年了 web app 还是没法取代 native app 的核心问题就在性能上，吹的再响用户体验的瓶颈就在那里。这 3 年前端界过于吹概念，考虑的更多的是“对开发者友好”，对用户体验关注度太低

上了年纪还敢加班熬夜的都是英雄，我是不敢的，怕死，为了不加班我可以做任何事情，无它，求生而已