1. 계층형 아키텍쳐의 문제
내가 겪었던 계층형 아키텍쳐의 문제
책에서 말하기 이전에, 내가 느꼈던 계층형 아키텍쳐의 문제들을 이야기해보려고 한다. 이는 개인적이고, 실력이 부족해서 그럴 수 있다.
- 서비스의 이름이 Entity에 종속적이게 된다. 따라서 어떠한 기능을 명세하는데 Entity를 기준으로 만들게 되는 경향이 생기는 것 같다. 유스케이스(시스템의 동작을 사용자의 입장에서 표현한 시나리오)를 명확하게 알 수 없다. 즉 클래스의 책임이 한 눈에 보이지 않는다.
이로 인하여 어떤 객체가 어느 위치에 들어가야 할지 확실하게 정의하기가 어려웠다. 이로 인하여 XxxService라는 Entity에 종속적인 클래스에 모든 책임을 작성하는 경우가 많았다. 즉 넓은 서비스가 생성되었다.
ex) 계층형에서 어디 들어가야 할 지 잘 모르겠는 클래스..
- RedisTemplate과 같은 영속성 계층에 있어야하는 객체들을 Service 단에서 의존성 역전을 사용하지 않고 바로 사용하더라도 아무런 제재, 약속이 존재하지 않는다.
private final RedisTemplate<String, Object> redisTemplate;- 기능이 아닌 구현체에 집착하게 되고, 구현체에 관한 내용과 데이터베이스의 따른 기능을 명세 하게 된다. 이로 인해 유연한 사고가 불가능해진다. (유스케이스가 떠오르지 않는다.)
public void saveAccountByMoneyWithUseLock(Money money)
// public void sendMoney(Money money)책에서 말하는 계층형 아키텍쳐의 문제
- 계층형 아키텍쳐는 데이터베이스 주도 설계를 유도한다.
- 우리가 계층형 아키텍쳐로 설계를 하게 되면, 가장 처음 하는 행동은 "XxxRepository"를 만드는 행위일 것이다. 하지만, 이 자체로 우리는 기능에 집중하는 것이 아닌 상태에 집중하는 것이다.
- 즉, 상위 계층부터 어떠한 기능이 필요하겠구나 -> 이러한 기능이 필요하니 이러한 데이터가 필요하겠다라는 흐름이 아니다.
- 지름길을 택하기 쉬워진다.
- 유틸리티나 헬퍼 컴포넌트들이 영속성 계층에 속할 수 있다. 계층형 아키텍쳐에서는 이것을 방지하는 규칙을 강제하지 않는다.
- 이 글이 잘 이해가 되지 않았다. 먼저 최근의 대부분의 프로젝트들은 Spring Data Jpa를 사용하기 때문에 기본적으로 영속성 계층에 헬퍼와 유틸리티 기능을 넣을 수 없었기 때문이다. 아래와 같은 코드를 보면 좀 더 이해가 쉬울 것 같다.
// Persistence Layer
public class MemberRepository {
private final Connection dbConnection;
public MemberRepository(Connection dbConnection) {
this.dbConnection = dbConnection;
}
public Member findById(int memberId) {
// 데이터베이스에서 회원 정보 조회
// ...
String formattedId = StringUtils.padLeft(String.valueOf(memberId), 5, '0');
// ...
}
}
// StringUtils 클래스
public class StringUtils {
public static String padLeft(String str, int length, char padChar) {
// 문자열 왼쪽에 지정한 문자로 패딩 추가
// ...
}
}
- 테스트하기 어려워진다.
- 컨트롤러가 엔티티 객체를 건들이는 경우를 생각해보자. 이 경우에 웹 계층에서는 서비스(도메인) 계층 뿐만이 아니라 영속성 계층도 모킹을 해야하고, 단위테스트의 복잡도가 높아지게 된다.
- 하지만 계층형 아키텍쳐에서는 이 또한 강제하지 않는다.
- 유스케이스를 숨긴다.
- 여러 개의 유스케이스를 담당하는 아주 넓은 서비스가 만들어진다. 여러 개의 컨트롤러에 종속적인 서비스(도메인) 계층이 생성될 수도 있다.
- 위 방식이 잘못된 방식인 이유는, 예를 들어 사용자 등록 유스케이스를 찾을 때, UserService에서 찾는 것보다 RegisterUserService에서 바로 작업을 하는 편이 훨씬 수월해지기 때문이다.
- 동시 작업이 어려워진다.
- 코드에 넓은 서비스가 존재한다면 서로 다른 기능을 동시에 작업하기가 매우 어렵다. 예를 들어서 Restaurant라는 Entity가 존재하고, 이에 관련된 RestaurantService에서 여러가지 기능을 사람 여러명이서 동시에 작업한다고 생각해보면 굉장히 쉽지 않을 것이다.
출저 : 만들면서 배우는 클린 아키텍쳐
노력하는 사람