👏 퍼사드 패턴 적용기
퍼사드 패턴에 대한 설명은 깃허브 에 있다.
리팩토링 진행도중에 좀 좋은 구조를 구성해서 적어본다.
🔥 개요
우선 Service 레이어에서 Repository를 너무 많이 의존하는것이 상당히 컸다.
여러군데에서 가져오는 것 사실 이것은 개발하면서 어쩔 수 없는 노릇일 수 있다.
그러나 의존을 너무 많이 가져간다는 것은 유지보수 측면에서도 힘들것이고,
응집도도 낮은 그런 클래스가 되어버린다.
그래서 일단 생각해 낸것은 우리는 객체지향을 사용하고 있다.
어떤 한 클래스는 조합하는것만을 목표로 하는 클래스가 있다면 어떨까🤔 하고 생각했다.
이 클래스를 생각한것은 기존 프로젝트에 테스트 코드를 추가하려고 하다보니까 고민하게 되었다. 🤔
기존 클래스에서 테스트를 하려면 너무 필요없는 의존성까지 추가해줘야해서 자칫하면 혼동을 불러올 수가 있었다.
그래서 생각한 것이 퍼사드 패턴...
이 퍼사드 클래스가 여러개의 Service 레이어를 두면 그것들을 한데 모아서
처리를 해주면 의존은 낮아지면서 응집도는 올릴 수 있을거라고 생각했다.
왜?
각각 역할에 대한 Repository 와 필요한 의존성만 가지고 하나의 Service로 나눈것을 퍼사드쪽에서
조립해서 써주면 지금과 같은 로직이 되면서 동시에 테스트도 잘 가져갈 수 있을거라 생각했다.
🔥 클래스 다이어그램
예를 들어 이런 클래스가 있다고 가정하자.
Repository 객체를 두개를 사용하고 있다.
이게 2개일 수 있고 그 이상이 될 수도 있다.
이 구조를 개선하려고 했던 다음 클래스 다이어그램을 보도록 하자.
이런식으로 하위 객체를 의존성을 1개씩만 갖게하고 퍼사드에서는 조합만 해주면 되는게 된다.
이렇게 되면 각 기능에 대한 단위 테스트를 깔끔하게 진행할 수 있고,
문제가 발생하는 로직에 한해서만 유지보수를 가능할 수 있게 되었다.
결국엔 Spring MVC 패턴이 그냥 이 퍼사드 패턴이 적용되어 있다 라고 생각하면 되지만,
아래의 의존성을 덕지덕지 붙여가면서 하나의 서비스를 뚱뚱하게 유지하기는 싫었다.
예시의 코드로 보자면
멤버와 아이템두개를 합쳐서 보여주는게 있다고 하자.
Member.java
public class Member {
private Long id;
private String name;
private String email;
}Item.java
public class Item {
private Long id;
private String name;
private int price;
//getter, setter 생략
}Repository
public class MemberRepository extends JpaRepository<Member, Long> {
}
public class ItemRepository extends JpaRepository<Item, Long> {
}레거시
@Service
public class FooService {
@Autowired
private MemberRepository memberRepository;
@Autowired
private ItemRepository itemRepository;
public void getMemberAndItem(int id) {
Member member = memberRepository.findById(id).orElseThrow();
Item item = itemRepository.findById(id).orElseThrow();
//두 값의 비즈니스 로직을 수행
return //두개를 합쳐 반환한다.
}
}간결하게 두줄만 작성했지만 벌써 두개 조회를 동시에 하고 안에서 로직을 구현하고 있으니 스파게티 코드가 생성될 것이 예상된다.
이 구조를 아래와 같이 변경한다.
개선안
기본적으로 생성자 주입으로 변경을 해준다.
public class MemberService {
private final MemberRepository memberRepository;
public MemberService(fianl MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
public Member findById(final int id) {
Member member = memberRepository.findById(id).orElseThrow();
// member에 대한 로직 수행...
return member;
}
}
public class ItemService {
private final ItemRepository itemRepository;
public ItemService(final ItemRepository itemRepository) {
this.itemRepository = itemRepository;
}
public Item findById(final int id) {
Item item = itemRepository.findById(id).orElseThrow();
// item에 대한 로직 수행...
return item;
}
}일단 서비스를 위와같이 두개로 분리한다. 그러면 각 Repository에 대해 해야할 일만 명확하게 구분이 되어진다.
이것을 사용할 퍼사드로 넣어주면 되는 것이다 👍
public class TogetherFacade {
private final MemberService memberService;
private final ItemService itemService;
public TogetherFacade(final MemberService memberService, final ItemService itemService) {
this.memberService = memberService;
this.itemService = itemService;
}
public void 전부를_만들어_돌려준다(final int id) {
//이미 비즈니스 로직은 각 서비스에서 실행되었다.
Member member = memberService.findById(id);
Item item = itemService.findById(id);
// 받은 그대로 조합식만 구성해주면 되는 것
//return....
}
}이렇게 되었을 때, 각 서비스 레이어부터 단위테스트를 잘 구성해서 퍼사드쪽으로 넘어올 수가 있다.
테스트만을 위한 코드작성? 이라고는 볼 수 없을 것 같다.
결국 모든 프로그래밍의 구조를 따진다면 조합해서 놓고보면 쭉 이어진 코드는 맞다.
하지만 객체지향의 의미는 해당 객체에게 메세지를 보내 기능을 수행하도록 구성하는게 바람직하다.
그렇기에 이렇게 분리해주면 오류가 어디서 나는지 명확하게 짚을 수 있다.
그러면서 단일 책임 원칙을 준수하게 된 아래의 레이어들이다. 🤩
여기서 더 어떻게 고쳐야하나? 라는건 나의 남은 숙제다 ㅋㅋㅋㅋㅋ
🔥 후기
일단 로직이 더러운것은 놔두고 각자의 역할만 따로따로 분리해서 만들고 보니
로직이 더러운게 아니었다. 그냥 모든 코드가 합쳐져서 한 메소드가
많은 일을 수행하고 있던거지 로직 자체가 이상하게 짜여져있는 것은 아니었다. (물론 이 클래스만 그랬을거다.)
Mocking을 하면서 Mockito로 각 서비스 레이어를 테스트하였다.
@Autowired로 되어있던 것을 생성자 주입으로 바꾸면서 이 테스트도 진행할 수 있게 되었던건데,
이것은 다음 포스트에서 자세하게 다뤄보도록 하겠다.
아무튼 구조를 개선하여 조금 더 깔끔하게 코드를 관리할 수 있게 되었다. 🤣
