Spring data jpa 官方支持的： http://www.github.com/querydsl/querydsl

1 、观察项目的依赖库：
java 的 pom，build.gradle ； 前端的 webpack ； android 的 manifest （ ios 不懂，但应该也有）。
相对新一些的项目，都会使用非常多的打包工具或者开箱即用的框架。如果不事先对工具链有一个初步的认实，很多自动化的配置看源码是找不到的。

2 、观察项目的代码（包、层级）结构：
一个项目的代码如何组织规类，很大程度上能够体现编程思想 。 例如经典的 MVC，MVP，DDD 。 知晓这些可以帮你较快的找到你希望首先了解的代码实现 。

3 、寻找接口路由、逻辑入口配置
任何软件的核心都是对外提供服务， 想要了解和学习，找到业务的入口是第一步。 通常较大的项目，为了降低维护成本。都会将接口、页面路由等配置进行统一的管理，并配以注解。

4 、善用 IDE 的 debug
走到这一步， 剩下的就是体力活了。 如果能将项目顺利运行起来。 利用 IDE 的 debug 功能 ，可以了解进程、调用堆栈、接口实现类等单纯看源码无法了解，却又非常重要的信息。

5 、不要发散思维，不要深入研究
以上……

去年中旬，有面试过一家在 V2EX 发招聘需求的公司。 而且有朋友在日本读大学。 对这个问题还是能分享一些我知道的内容。
先抛开对日派遣是否存在培训欺诈的问题。 日本一个普通应届生的薪资水平大概在 20 - 28W 每月。故赴日开发薪资为 22W 是一个合理的值。 此处要多说明一下， 在日本，IT 码农，属于中低端职业。同时，日本的大学毕业生的质量与社会地位，较国内是高不少的。

趣店的本部的确要搬厦门……

就楼主提出的 2 个方案比较， 明显方案 2 更加符 restful 接口的设计规范。
对于“用户”和“项目”两个概念， 可以根据具体的系统功能来从两者之间找寻一个 ”聚合根“，作为数据引用的入口。
至于权限上， 个人觉得可以将 读、 写两种权限分别看待。 对于只读接口，权限可以相对放宽一些。 而写操作，一般也只会允许项目所属的用户进行编辑。而不是单纯从”用户“ 、 ”项目“ 两个概念上单独的去考虑权限。

很奇怪为何 业务层不能抛异常？ 这种主动抛出的异常本身就属于业务逻辑的一部分。
从另一个方面来说， 异常设计的初衷就是由调用方去处理， 领域层只需要实现业务并遵循领域规则就好。