Java项目的代码，你们都是怎么设计分层的？分层有什么好处？
在我看来，Java项目分层简直就是必须的，就算是一个人独立发开的项目，也应该进行代码分层；我现在负责的项目，并没有参考什么代码分层规范，因为项目的框架都是我一个人搭建的，我也是凭着经验做的设计，有些地方还掺杂了一些个人的喜好。
分包
我们项目被分成几个包，但是并不是微服务那种程度，因为公司的一些基础还不是非常的完善，比如容器、容器管理工具、持续集成，虽然已经起步，但是并没有成熟到让生产环境使用的程度，毕竟是金融行业，求稳大于创新。
我们项目现在是按照功能模块分的包，比如接口服务、定时服务、前端页面、监控等等；
前端页面是纯前端（我不太确定这样形容是否明确），页面所需的数据都是通过调用接口获得，本身不和数据库发生交互；
其余工程都可以独立部署，关联功能，都是通过MQ进行解耦。
分层
单个工程中，分层设计都一样，也和主流的代码分层差不多（我们的项目绝大部分功能都是接口，少量的页面功能，也被分到单独的包中了）：
DAO层：Data Access Object，数据访问对象，我们用的是MyBatis，在方法的注解中写SQL语句；
Service层：业务逻辑层，这里可能调用其他的Service或DAO；我看有些系统Service层会分成两部分，一部分是功能比较单一的业务逻辑，另外一部分是组合的业务逻辑；个人认为这样有些繁琐；
Controller层：请求处理层，包括入参回参的类型转换、入参验证等功能在这里完成；
Model层：数据的实体对象，和数据库列名保持一致；类名也都是以Model为结尾命名；
Domain层：我们把入参和回参单独做了一层，没有和Model层混在一起；就算一个接口要查询一个单表，查询结果也要把Model转成Domain；我们在Domain这一层做了很多字段的标准化，保持见名知意；Domain层中的内容确定好了之后，属性名称不会改变，但是Model层中的内容允许修改。
剩下的就是Util、Contants、Config等等。
分层的好处
分包和分层，看起来让代码结构变得更加的复杂，这种结构的复杂，实际上却可以降低系统的复杂度：
单一职责：每一层的代码，只负责一类的职责，职责边界变得非常的清晰；
高内聚、低耦合、易维护：业务逻辑被放到了一起，修改的时候不仅快，而且不会有遗漏；如果业务逻辑分散在多个代码层，那么修改的时候，需要修改多处的代码，这样难免会有疏漏；上层代码依赖下层代码，条理清晰，不会有循环依赖；
复用性高：某项功能被抽象出来，可以复用给多个业务流程。