DAO랑 service랑 차이가 없던데 무슨차이죠?

초보입니다.DAO랑 service랑 차이가 없던데 무슨차이죠? 
아래는 소스입니다. 

package test.dao; 

import java.util.List; 

import test.web.dto.BoardDTO; 

public interface BoardDAO { 
public BoardDTO getBoard(String accno) throws Exception; 
public List<BoardDTO> getBoardList() throws Exception; 
public String insertBoard(BoardDTO boardDTO) throws Exception; 
public void updateBoard(BoardDTO boardDTO) throws Exception; 
} 




package test.service; 

import java.util.List; 

import test.web.dto.BoardDTO; 

public interface BoardService { 
public BoardDTO getBoard(String accno) throws Exception; 
public List<BoardDTO> getBoardList() throws Exception; 
public String insertBoard(BoardDTO boardDTO) throws Exception; 
public void updateBoard(BoardDTO boardDTO) throws Exception; 
} 

DAO는 daoImpl로 구현하고 service는 serviceImpl로 구현 
하잖아요? 근데 어떤 소스 보니깐 내용도 메소드도 
모두 dao와 service가 동일하던데 왜 그런 건지요? 
Dao와 service가 각각 어떤 역할을 하는지 여쭤봅니다. 
struts에서 action이 하는 역한을 스프링에서는 controller가 
한다는 것 처럼요. 그리고 과거 dto패키지를 스프링에서는 
다르게 사용하던데 model 패키지와 domain 패키지중 어떻게 
쓰는것이맞는지요? 어느것이 좀 더 정확한 표현이라고 
할 수 있는가요? 

---

DAO와 Service는 그 역할이 분명히 다릅니다. 
DAO는 단일 데이터 접근/갱신만 처리합니다. 
Service는 여러 DAO를 호출하여 여러번의 데이터 접근/갱신을 하며 그렇게 읽은 데이터에 대한 비즈니스 로직을 수행하고, 그것을 하나의(혹은 여러개의) 트랜잭션으로 묶습니다. 

즉, Service가 트랜잭션 단위입니다. 

위와 같이 DAO와 Service가 완전히 동일해지는 경우도 분명히 발생합니다. 하지만 그것은 해당 비즈니스 로직이 "단일 DB 접근"으로 끝나기 때문에 발생하는 것입니다. 

만약 DAO의 메소드 하나에 다중 DB접근 로직이 들어갔고, 서비스는 단순히 그 DAO메소드를 호출하는 통로 역할만 한다면 DAO측 모듈화가 제대로 안된 접근 방식일 가능성이 높습니다(항상 그렇다는 뜻은 아닙니다) 

---

뭔가 데이터를 직접 읽고 쓰는 코드가 들어간 부분을 DAO로 보시면 될듯.. 
그게 DB가 됐든 파일이 됐든.. 
서비스단에서 데이터 입출력을 추상화 하려고 만든게 DAO니까요. 

만약 서비스단에 데이터 입출력 코드가 들어가 있다면 잘못된 설계라고 봅니다.

---

풋프// 
javaman님이 말씀하신 프레임웍에는 데이터를 직접읽고 쓰는 코드가 없습니다..ㅎㅎ;; 
약간 개념이 달라진 부분이긴한데..음... 

javaman님의 질문에 결론적으로 말씀드리면, 
persistence가 기존 dao의 역활을 한다고 보시면 됩니다.. 

허나 이 프레임웍은 개념을 달리해서 최소한의 프로그램을 지향하는듯 합니다.. 
기존의 dao/action/form...등등의 개념에서는 dao가 하는 일은 아키가 정하기 나름이였죠.. 
플젝마다, dao를 데이터를 가져오는 기능만 하도록 하는 곳이 있는 반면, 
dao를 '완전' 객체개념으로 설계해서, 하나의 프로세스가 되도록 하는 곳도 있었습니다.. 
예를 들어, dao를 만들때 필수 파라미터만 받아서 처리를 하는 최소한의 객체로 사용할수도, 아니면 dao를 호출하는 service의 영향을 받아서 하나의 프로세스 개념으로 하는곳도 있었죠.. 

둘의 차이는 업무의 차이로 인해 벌어진 일이라고 생각은 들었지만..(tx를 어디서 관리하느냐도 중요한 설계포인트였죠..한 플젝에서 무작정, service단!! 혹은 dao단!! 이라고 할수 없는 업무가 분명 존재하죠..ㅡㅡ;;) 
두번째가 어려운 업무처리를 할때에는, 만들기가 쉬워서 많이들 했던거 같더라구요.. 
개인적으로 근데 솔직히 두번째는 엄밀히 말해 DAO가 아닌 service를 좀 더 쉽게 가져가기 위한 거였지, 진정한 Data Access 객체는 아니였던거죠.. 

그래도 어쩌겠어요.. 
지금 output은 dao에 약간의 로직을 첨가한게 더 빠르게 나오는데..ㅡㅡ;; 

말이 길어졌는데요..ㅎㅎ;; 
현재 spring과 ibatis에서 지향하는 프레임웍의 코딩 방법은 각 모듈에 맞게 최소한의 로직으로 구성하는데 있는듯 합니다.. 

그래서 점점 파일이 많아집니다..ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

출처 - http://www.okjsp.net/seq/179628