在用三层架构进行开发的时候有很多困惑，比如：
① Service层的话需要和Dao一一对应吗，比如有BookDao，是不是有一个BookService然后BookService里面有crud方法。这种方式合理吗
或者说我应该按照业务来划分，比如是人买书，那我就应该给这个行为建一个service类，可是这样的话对于人和书的crud方法应该放在Service层的哪里呢
② 还有一个问题是Service层的公共方法，比如人买书这个行为需要先看数据库里有没有这本书，人读书这个行为也需要这一步校验，这种类型的校验多了我肯定需要把他们抽离出来，但是我应该抽离成一个独立的Service还是做成工具类？
要是做成工具类的话，工具类可以引用Dao？因为这些校验需要查数据库。
③ 感觉最近做项目对于这些架构的问题很头疼，有没有想过的书或视频可以系统解答一下怎样写出合理的项目的，主要是合理的项目代码架构这方面。
你要知道，很多时候，你的多个目标是需要相互妥协才能找到折衷的办法的。
好比往往价廉物美是不可得的，你追求物美，就要多花钱，你要追求价廉就要对质量妥协。
在软件的设计方面来说，容易阅读的代码必然是简洁的代码。但是如果你要易于拓展，必然就要加重代码的复杂程度。比如说，你直接调用数据库这个就是简单。
你要分层，然后调用一个接口，而把实际数据库的操作放在DAO，再实现这个接口，的确容易扩展了，替换数据库不需要改主程序，但是就不容易读了。
所以，有经验的架构师和学生党的区别就是，前者才知道如何取舍，而讲理论，后者头头是道。
首先，你说的这些算是通用的编程思路基于 MVC 框架的 Controller -> Service -> Dao 层的结构来写代码。
而且，小功能也没有必要严格按这三层来，之所以有这个三层之说，一般来说为了可扩展，如果Service 层业务变动，不会影响 Controller 。
第二个问题的纠结之处，还是要分层的 DAO 就是数据库的基本的 CRUD ，而 Service层是按照业务逻辑调用 DAO 的。至于是工具类还是服务类没有什么区别，都可以的。
这也算不上架构方面的问题，不要纠结，跟着你们公司的项目风格走就行了。
个人认为：
1、Dao层应当与数据表一一对应，即按照表逻辑进行创建，对应表的增删改查在对应的Dao层；
2、Service层与Controller层则按业务逻辑来
3、通过上两点之后，发现，一个Service层中可注入多个不同的Dao层对象，进而完成=业务逻辑中对各个数据表的操作
多使用设计模式，将设计默认运用到炉火纯青的时候，就可以写出优质的代码，还有就是严格自己遵守开发规范，再次就是优化自己的代码，
我相信，优质的代码绝对不是一次就能够写出来的，它需要经过多次的优化而来。