[JAVA] Controller-Service-Repository 3계층 아키텍처

1. 강한 결합의 문제점

처음 코드를 짤 때는 ArticleController가 사용자 요청 받고, 검증하고, 리스트에 저장하고, HTML 응답까지 혼자서 처리했음.

• 문제점: 요구사항이 하나만 바뀌어도 컨트롤러의 코드를 다 뒤져야 함. 클래스 하나가 너무 많은 걸 처리하고 있는 상태였음.

---

2. 역할 분담

그래서 역할을 3개로 나눴음. 이로 인해 각자의 책임이 명확해짐.

계층 (Layer)	역할
Controller	외부 요청 수신 및 응답 반환
Service	비즈니스 로직 및 규칙 처리
Repository	데이터 저장 및 조회 (DB 접근)

---

3. 각 계층 세부사항

ArticleRepository:

데이터를 어디에 어떻게 저장할지만 고민함. 지금은 메모리지만, 나중에 MySQL이나 Oracle로 바뀌어도 여기만 수정하면 됨.

ArticleService:

가장 중요한 규칙들이 모이는 곳임. "욕설이 포함되어 있는 게시물인가?" 같은 판단은 여기서만 수행함. 컨트롤러나 리포지토리는 이런 복잡한 사정을 몰라도 됨.

• 핵심 기능: 규칙 검증 후 Repository에 작업 위임

ArticleController:

사용자가 보낸 데이터(Rq)를 정리해서 Service에 전달하고, 작업 결과를 돌려주는 역할만 함. DB가 어떻게 돌아가는지 전혀 알 필요가 없음.

• 핵심 기능: 요청 파라미터 추출, 결과 응답 처리

---

4. 왜 이렇게까지 해야 할까?

이렇게 구조를 잡으면 변화에 유연하게 대처할 수 있음.
예를 들어, 아래와 같은 수정 사항이 생겼다고 가정해 보면?

• "DB를 MySQL로 수정" → Repository만 수정하면 끝
• "중복 제목 금지: → Service에 로직 한 줄 추가하면 끝
• "모바일 앱용 API 응답 요청" → Controller만 새로 만들면 끝

---

핵심 요약

1. 계층 분리: Controller → Service → Repository 순으로 의존함.
2. 단일 책임 원칙(SRP): 한 클래스는 자기 할 일만 잘하면 됨.

---