레거시 코드, 빈약한 도메인 모델(Anemic Domain Model)
이전 시간에 잘못된 소프트웨어를 언급했었다.
이번에는 잘못된 소프트웨어를 지칭하는 대표적인 용어 레거시 코드를 간단히 알아보고
그중 하나인 빈약한 도메인 모델을 알아보려 한다.
레거시 코드
레거시란 용어를 말하면 누구나 다음과 같이 비슷한 생각을 할 것이다.
- 매우 악취가 풍기는 코드
- 파악하기 힘든 코드
- 의존성이 매우 강하게 결합된 코드
- 전혀 의미를 알 수 없는 변수명과 함수명
- 큰 진흙 덩어리
- 테스트코드 작성하기 두려운 존재
- 기타 등등
즉, 이해할 수 없고 수정하기도 힘든 코드를 뜻하는 경우가 많다.
이런 레거시 코드의 특징은 새로운 기능이 추가될수록 점점 감당하기 어려워진다.
하지만 레거시 코드를 기피할 수 없다. 언젠간 극복해야할 과제다.
빈약한 도메인 모델 (Anemic Domain Model)
객체지향에서 오브젝트는 상태(state)와 행위(behavior)로 구성되어 있고, 문맥 속에서 협력을 해야 한다.
하지만 자바 엔터프라이즈 개발에서 사용되는 데이터 홀더 개념의 단순 오브젝트는 상태(state)만 가지고 있다.
이를 빈약한 도메인 모델이라고 한다.
public class User {
String id;
String name;
String password;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}레거시 코드에서 흔하게 볼 수 있는 빈약한 도메인 모델이다.
이런 빈약한 도메인 모델을 사용하기 위해서, Business Object와 서비스 레이어 사용을 과도하게 부추기게 된다.
Business Object
빈약한 도메인 모델의 비즈니스를 구현한 오브젝트로 동작을 실행하거나 관리하는 클래스다.
클라이언트 데이터에 대한 요청을 DAO에 호출하기도 한다.
거대한 서비스 레이어 (Big Service Layer)
객체지향 설계 원칙에 맞지 않고 도메인을 가져와 사용해서 각 서비스 레이어마다 도메인 로직이 발생한다. 즉 도메인 로직의 분산을 뜻한다.
예) 메뉴, 주문, 카테고리 등 다양한 레이어에서 상품 오브젝트를 가져다 사용
또한 서비스 레이어마다 다양한 도메인을 사용하니 재사용하기 힘들 정도의 난잡하고 거대한 코드를 가지게 된다.
지금도 이런 방식으로 개발하는 곳이 많이 존재한다.
해결 방법?
레거시 코드를 객체지향 설계 원칙에 맞게 변경하는 방법은 리팩토링뿐이다.
하지만 리팩토링을 하기 전에 앞서 레거시 코드에 대한 테스트 코드 작성이 필요하다.
다음에는 테스트 코드를 알아보자.
* 잘못된 내용이 있으면 댓글 부탁드립니다.
참고자료