🏛 Facade Pattern

올해 6월 말 쯤부터 8월 초까지 달렸던 동아리에서 Spring Boot, Java, MySQL을 활용한 프로젝트를 진행하였다.

동아리에서는 장고를 가르치고, 개발 기간이 턱 없이 부족하던 터라 충분히 공부하고 프로젝트를 진행할 수 있는 시간이 적었다. 그 결과 10월 말인 지금까지 릴리즈를 준비하며 동시에 꾸준히 리팩토링 해왔다.

특히 같이 개발하는 팀원도 리팩토링의 필요성을 너무 느꼈던 터라, 논의 후 수월하게 리팩토링 할 수 있었다.

해당 프로젝트 내용을 본문에서 예시로 들기 때문에 간단하게 설명하자면, 유저가 가족에 가입하고 가족 구성원들과 함께 챌린지를 할 수 있는 형태의 서비스이다.

먼저 간단하게 문제를 이해하기 위한 개념들을 정리하였다.

---

의존성 주입

의존성 주입은 외부로부터 필요한 객체를 주입 받아 사용하는 것이다.

MVC 모델로 개발함에 있어서, Controller에서는 Service의 모듈을 호출하고 Service에서는 Repository(DAO)의 모듈을 호출하는 일이 발생한다. 이 때, Controller는 Service에 의존하고 Service는 Repository에 의존한다고 말할 수 있다.

위의 예시에서는 UserService가 UserRepository에 의존하며, @RequiredArgsConstructor 어노테이션을 통해 생성자 주입을 해주고 있다.

---

ACID

ACID는 아래와 같은 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질이다.

Atomcity(원자성) : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력

Consistency(일관성) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것

Isolation(독립성) : 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것

Durability(지속성) : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함

Spring에서는 위와 같은 @Transactional 어노테이션으로 간단하게 해결할 수 있다.

---

아키텍처

다음은 해당 프로젝트 아키텍처의 변천사다.

1차 아키텍처

처음 프로젝트의 아키텍처는 위와 같았다. Controller와 Service가 일대일 매핑 되어 있었고, 각 서비스가 필요한 모든 Repository에 의존하고 있었다.

여기서 문제가 발생했다.

예시의 가족 나가기 기능은 유저 탈퇴 기능 안에 속해 있다. 이런 경우에도 같은 로직이 다른 Service(각각 ChallengeService, FamilyService, UserService)에 중복하여 존재하였고, 간단한 로직이 바뀌어도 일일이 바꿔줘야 하는 등 재사용성 및 유지보수성이 떨어졌다.

이로 인해 아키텍처를 아래와 같이 바꾸게 되었다.

2차 아키텍처

Repository(DAO)를 Service 레이어와 일대일로 매핑되게 변경하고, Controller 레이어의 의존성을 두텁게 만들었다.

여기서 또 다른 문제가 발생하는데, Controller 계층에서는 @Transactional 처리가 불가능하기 때문이다.

유저 탈퇴 기능의 경우, 가족 구성원 삭제 이후 유저 삭제가 일련의 과정으로 그 원자성이 보장되어야 한다. 하지만 Service 레이어에서의 트랜잭션 처리만으로는 유저 삭제에서 DB 변경에 실패해도 가족 구성원 삭제로 이미 바뀐 데이터는 롤백되지 않는다. 즉, ACID가 박살이 난다.

고민 끝에 Service 레이어를 하나 더 추가하기로 했다.

3차 아키텍처

위와 같이 레이어를 하나 더 추가했고, 이름은 Mapper라고 지었다.

이 구조의 한 장점은 일단 같은 로직의 코드가 여러군데 중복되지 않는다는 점인데, 특히 의존하는 레이어의 모듈을 호출한 뒤 반환 받은 결과에 대응하는 로직이 다양할 때 편리했다. 이전에는 Service 레이어에서 특정 로직을 계속해서 반복해야 했던 반면, 이 구조에서는 반복되는 로직을 Service 레이어에 작성해둔 뒤 Mapper의 다양한 모듈에서 호출하는 등 재사용이 용이해졌기 때문이다.

또, Service 레이어에서 데이터 관련 검증을 하고 Mapper에서는 비즈니스 로직을 구현하는 등 그 기능을 명확하게 나눌 수 있었다. Mapper 레이어에서 Controller로 값을 반환할 때는 DTO로 감싸, Entity 자체가 노출되지 않도록 하였다.

프로젝트의 가족 나가기와 유저 탈퇴 기능 역시 위와 같이 리팩토링 되었다. 현재까지 프로젝트를 진행하며 나온 문제들은 모두 보완해준 아키텍처이지만, 여전히 다른 더 좋은 방법이 있지 않을까 고민이 된다.

---

아키텍처는 무조건 이게 맞다라고 할 수 있는게 없어서 더 어려운 것 같다.
DDD를 공부 중인데, 다음 프로젝트에는 DDD를 적용해보려고 한다!