🎨

도메인 구조 우아하게 설계하기

생성일

2022/11/29

태그

Refactoring

Spring

Structure

JPA

목차

배경

저희 모락은 스프린트 5를 시작하면서 요구 사항 이외에 함께 해야 할 일들에 대해 회의를 하였습니다. 캐싱 서버, 기능 추가 등 흥미로운 주제들이 나왔는데 그 중에서도 도메인 재설계에 대한 욕구가 가장 컸습니다. 모든 백엔드 팀원이 도메인에 대한 대공사를 원하기도 했고, 계층 구조 재설계에 대한 흥미도 컸기때문에 이번 스프린트 5에서 도메인 재설계를 대대적으로 하기로 결정하였습니다. 일정 상으로 일과 중에는 인덱스, 쓰레드 설정을 포함한 요구 사항, 일과 후와 주말에는 도메인 재설계를 진행하기로 하였습니다.

문제점

먼저 스프린트 1-4를 진행하면서 느낀 코드의 문제점에 대해 공유해 보았습니다.

•

의존 관계가 얽혀있다.

◦

Poll  PollItem, PollItem  PollResult 등 서로가 서로를 너무 잘 알고 있습니다.

•

서비스 계층 하나에 많은 로직이 집중된 구조이다. → 하나의 객체가 너무 많은 역할을 가지고 있다. 

메서드 하나로 모든 비즈니스 로직을 처리하는 약속잡기의 일그러진 영웅

위의 상황에서 발생할 수 있는 문제로는 상호 참조하는 구조로 관리가 어렵다는 점과 비즈니스 로직이 서비스 계층에 있어 응집도가 부족하다는 점 등 2가지가 있습니다. 이 문제를 해결하기 위해서는 단방향 의존성을 가지는 구조로 설계하고, 가장 중심이 되는 도메인에 비즈니스 로직을 넣어 응집도를 높여야 한다고 생각했습니다. 이와 같은 방식으로 리팩토링을 한다면 도메인 객체를 수정해야 하고, 순차적으로 영속화 계층, 서비스 계층도 영향을 받게 되는 커다란 공사를 진행하게 됩니다. 그리고 이 상황에서 서비스도 유지해야 했기때문에 약 4주의 기간을 잡고 도메인 재설계를 시작하였습니다.

목표

설계 및 개발하기에 앞서 우리의 목표부터 새로 다잡고 진행하는 것이 먼저였습니다.

우리가 설계하고 코드를 짤 때 컨셉을 잡고 항상 우리의 철칙과 이유를 생각하고 정리하도록 한다. 

→ 모든 코드에 이유와 손때가 묻어나는 것이 첫번째 목표였습니다. 프로젝트 초기에는 시간 내에 서비스를 완성시켜야 했기때문에 코드를 부랴부랴 짰고, 이후 짠 코드를 다시 보면 ‘우리가 레벨 1, 2때 뭐 배웠더라’ 라는 생각을 많이 하게 되었습니다. 물론 프로젝트의 상황과 환경에 맞게 코드 퀄리티는 잠시 제쳐두고 서비스를 시간 내에 개발하는게 그 당시의 목표였습니다. 이에 따라 우리가 만든 레거시는 우리가 치우자! 라는 마인드로 레벨 1, 2기간 배운 클린 코드, 자바의 특수성 등을 활용하여 의미있고 깔끔한 코드를 작성하고자 하였습니다.

위의 목표를 조금 더 구체화하면 다음과 같습니다.

•

의존성 흐름을 단방향으로 바꾼다.

•

도메인 구조를 객체지향적으로 새롭게 구상해보고 기존의 구조와 비교해본다.

예외를 발견할 때마다 검증 로직을 추가하다보니, 이후 해당 로직을 볼 때 어떤 검증 로직이었는지 저도 헷갈릴 때가 많았습니다(그런데 git blame 을 보면 sungsan kim). 그래서 이 부분에 대한 가독성을 높이고자 하였습니다. 또한 많은 비즈니스 로직들이 서비스 계층과 DB 쿼리에 종속적이었습니다. 이러한 로직들을 도메인 객체 내부에 넣어 응집도를 높이고자 하였습니다.

마지막으로 의존성을 단방향으로 흐르게 구조를 변경하고자 하였습니다. 도메인간에 양방향을 가지고, 서비스 계층간에서 서비스끼리 서로 의존하는 구조는 순환 참조에 빠질 우려가 있었기 때문입니다.

도메인 설계하기

문제 원인 파악

기존의 서비스 계층에서는 레포지토리의 메서드와 비즈니스 로직이 함께 어울려 놀고 있었습니다. 이와 같은 상황이 특수하다고 볼 수는 없습니다. JPA 메서드와 간단한 비즈니스 로직이 있는 것은 익숙하고, 오히려 개발 초기 빠르게 개발할 수 있기때문입니다. 하지만 검증 로직과 비즈니스 로직이 복잡해지고, 다양한 JPA 메서드를 활용하게 되면서 점점 유지, 보수 하기가 힘들었습니다. 또한 도메인 객체에는 getter 와 생성자가 가득하고 생성 시 검증하는 로직이 전부였습니다.

레벨 1, 2 과정에서 미션을 할 때에는 도메인 객체에서 이러한 구조를 자주 보지 못했었습니다. 그래서 왜 이렇게 되었는지 곰곰히 생각해 보다가 저희 서비스의 회원, 팀 도메인 객체를 만들던 때를 회상했습니다. DB 스키마를 먼저 설계를 한 뒤 해당 테이블과 연관 관계에 맞춰 도메인 객체를 생성하였습니다. 그러다보니 객체가 역할과 책임을 가지는 구조가 아니라, 데이터 중심적인 구조가 되었다고 추측하였습니다. 이에 따라 DB라는 개념이 없는 콘솔의 세계관에서, 우리가 만든 도메인 객체를 중심으로 사고해보기로 하였습니다.

도메인 설계 초안

전체 기능이 투표, 약속잡기 두 가지가 있었고 시간의 효율성과 협업을 위해 각 기능을 두 명씩 맡아 페어 프로그래밍을 하면서 도메인 재설계를 진행하였습니다. 이에 따라 엘리와 저는 투표, 차리와 배카라는 약속잡기를 맡았습니다.

도메인을 그려보기 전에, 건축가 수저인 엘리가 다음과 같은 말을 해주었습니다.

•

시공이 아니라 디자이너의 관점에서 생각해본다.

•

실력이 쌓이면 디자인을 하는 단계에서도 시공을 생각할 수 있는 사람이 되자!

이 말이 크게 와닿았습니다. 하나의 건물을 지을 때에도 디자이너, 시공사 등 다양한 도메인을 가진 사람들이 협력하여 완성한다고 합니다. 기존에 저희가 만든 건물은 시공사가 디자인까지 직접 개입하여, 빠르게 지을 수는 있었지만 미적인 아름다움이 없는 것은 물론이고 어디가 계단이고 어디가 방인지 알아차리기 힘든 구조였습니다. 그렇다고 디자이너만 있으면 시공 시에 필요한 효율적인 계단 수, 지탱할 수 있는 자재 등을 실제 건설 현장에서 알아차리기는 힘듭니다. 그래서 처음에는 디자이너의 입장에서 건물 내 기능들에 대한 위치와 전체적인 구조 등에 대해 디자인하고, 실제 건물을 지을 때에는 만들어 놓은 디자인을 바탕으로 실제 현장의 상황에 맞게 수정을 하면서 리모델링을 완성해 보기로 하였습니다.

•

이전 도메인 구조

•

새로운 도메인 구조 초안

각 도메인은, 지금까지 만든 비즈니스 로직에 필요한 최소한의 멤버 변수만 가질 수 있도록 구성해 보았습니다. member가 team에 속하는지 확인하는 로직은 공통 로직이기 때문에 해당 검증 로직을 기존 도메인에서 분리하였습니다. 이에 따라 Member 와 Team 객체를 가지고 활용할 수 있는 로직이 없기때문에 Member 와 Team 객체를 간접 참조로 바꾸어 의존도를 낮추었습니다.

그리고 양방향으로 참조하던 구조를 단방향으로 바꾸었습니다. Poll Item 객체에서 Poll 에 대한 의존을 분리하였는데, 예를 들어 Poll Item 에서는 Poll 에 있는 투표 제목 등과 같은 정보로 활용할 수 있는 로직이 없기 때문에 Poll Item 에서 Poll 을 참조할 필요가 없었습니다. 또한 Select Members(구 Poll Result) 는 자신이 어떤 Poll Item에 투표했는지 알 필요가 없었습니다. 투표 항목 내용은 선택 인원(투표 결과)에서 알 필요 없이, 투표한 멤버와 투표 이유만 알면 되기때문입니다. 그래서 Select Members 에서도 Poll Item 에 대한 의존도 분리하게 되었습니다.

도메인 재설계 JPA 적용

먼저 설계한 이미지에 맞춰 도메인 객체와 멤버 변수를 만든 뒤, JPA 에 적용해 보고자 하였습니다. JPA 적용 시 주의깊게 봐야할 부분에 대해 고민해 보았습니다.

•

의존한 field 가 적절하게 column 과 연관 관계로 적용되는가

•

도메인 로직으로 추가, 변경, 삭제된 데이터가 적절하게 적용되는가

값 객체와 일급 컬렉션으로 포장한 객체에 대해 JPA 는 @Embedded, @ElementCollection 과 같은 어노테이션으로 확인하고 적용합니다. 그리고 도메인 로직으로 인해 변경된 사항에 대해서는 따로 update 쿼리를 날리는 대신, JPA 가 dirty checking 으로 변경점을 확인하고 변경 쿼리를 날리는 방향으로 구상하였습니다.

•

@Embedded, @Embeddable

검증 로직과 도메인 로직을 분리하기 위해 title, items 등의 변수는 값객체와 일급 컬렉션 객체로 포장하였습니다. 이러한 객체는 물론 DB 의 타입으로 없기에, 해당 객체 내부의 DB 타입과 매핑될 수 있는 변수를 찾고, 해당 변수를 DB 의 column 으로 선정합니다.

•

@ElementCollection

Specifies a collection of instances of a basic type or embeddable class.

컬렉션을 값 타입으로 저장할 때 사용합니다. 비교할 수 있는 대상은 @OneToMany 가 있는데 가장 큰 차이점은 컬렉션의 제네릭으로 선정되는 타입이 @Entity 인지 @Embedded 또는 기본 타입(String, Integer)인지의 차이입니다. 애플리케이션 관점으로 보았을 때로 차이점을 생각해보면 해당 객체가 유일하고 다른 객체와 구분이 되고 독자적인 생명 주기를 가지는 성격을 지니는지, 아니면 다른 객체에 속하고, 생명 주기가 소속된 객체에 종속적인지로 판단하였습니다.

SelectMembers 라는 도메인 객체는 각각의 투표 항목에 대한 투표 이유를 저장하는 객체입니다. 해당 객체에서는 컬렉션 타입으로 앞서 언급한 판단에서 후자에 속하여 @ElementCollection 을 사용하였는데요, 조금 특이한 점은 컬렉션 중 Map 을 사용했다는 점입니다. 각각의 투표 항목인 Poll Item 입장에서 보았을 때 자신을 투표한 사용자와, 사용자가 해당 투표 항목을 선택한 이유를 가지는 것이 타당하고, 투표 항목에 대해 사용자는 한 번만 투표할 수 있습니다. 만약 다시 투표한다면 이는 투표 재선택이라는 비즈니스 로직이 되어, 기존의 해당 투표 항목에서 선택한 멤버(Map 의 Key)를 찾고, 기존의 투표 이유(Value)를 변경하게 됩니다. 그리고 JPA 는 이러한 Map 과 같은 컬렉션도 깔끔하게 처리해 줍니다.

•

@CollectionTable

Specifies the table that is used for the mapping of collections of basic or embeddable types.

@ElementCollection 을 아주 단순하게 생각하여 연관 관계 매핑을 한다 를 JPA에 알려주는 거라면, @CollectionTable 은 새로 생성되는 컬렉션 타입에 대한 테이블에 대한 부가 정보를 명시하는 것이 목적입니다. 처음에는 변수 명이 selectMembers 라서 테이블 명으로 select_members 가 들어갈 것으로 예상했습니다. 하지만 저희는 테이블 명은 단수로 통일했기때문에 name = "select_member" 라는 옵션을 넣어주었습니다. (추가. 포스팅을 하면서 name 옵션을 떼고 실행해보니, poll_item_select_members 라는 테이블 명으로 매핑 테이블 이름처럼 생성되었습니다)

JPA 테이블 생성을 위한 기본적인 세팅이 완료되어 ddl-auto 옵션을 create-drop 으로 잠시 변경한 뒤 로컬 서버에서 서버를 실행해 보았습니다.

문제 1. 불필요한 매핑 테이블 생성

Poll 과 Poll Item 사이 구조는 @OneToMany 단방향입니다. 그래서 Poll Item 에 대한 제어권을 Poll 이 가지고 있습니다. 하지만 DB 에서는 이와 같은 관계를 표현하기 위해서는 Poll 에 대한 정보를 Poll Item 이 외래키로 가지고 있습니다. 이에 따라 @ManyToOne 이라는 어노테이션이 없다면 JPA 는 참조 테이블에 컬럼을 추가하는 대신, 다대다 관계에서 사용하는 매핑 테이블을 새로 생성합니다.

// 생성된 매핑 테이블.
create table poll_values (
       poll_id bigint not null,
        values_id bigint not null
    )

// auto increment 되는 PK 없이 poll item id 에 unique 제약 조건을 추가한다.
alter table poll_values 
       add constraint UK_svhq3p4dudwno4rl9gqxv0ohr unique (values_id)

alter table poll_values 
       add constraint FKklk455ytxmer2rri215keq7l9 
       foreign key (values_id) 
       references poll_item
    
    alter table poll_values 
       add constraint FKhfe8b8s1xteaqqeoakyb1jkap 
       foreign key (poll_id) 
       references poll
Java
복사

하지만 Poll 과 Poll Item 관계는 일대다 관계이기때문에 굳이 매핑 테이블을 생성할 필요가 없습니다. 그렇다고 @ManyToOne 을 적용하면 양방향으로 흐르게 되고, @ManyToOne 단방향은 애플리케이션 환경에서 제어권을 Poll Item 에 넘겨주게 됩니다. 그래서 지금의 구조에서 기술적으로 풀어내야 해서 고민하던 와중에 3기의 손너잘로부터 해결 방법을 듣게 되었습니다.

@OneToMany(cascade = CascadeType.ALL)
@JoinColumn(name = "poll_id", nullable =false, updatable =false)
private List<NewPollItem> values =new ArrayList<>();
Java
복사

@JoinColumn 어노테이션을 추가하고, 옵션으로 nullable 과 updatable 을 false 로 설정하면 JPA 가 매핑 테이블을 생성하는 대신, 일대다 구조의 외래키 구조로 설정합니다.

create table poll_item (
       id bigint generated by default as identity,
        subject varchar(255),
        poll_id bigint not null,
        primary key (id)
    )

alter table poll_item 
       add constraint FKs2aqtb9wm719gknvljgyf0ybp 
       foreign key (poll_id) 
       references poll
Java
복사

위의 설정덕분에 @OneToMany 단방향인 일대다 구조로 테이블을 설정할 수 있었습니다.

문제 2. 컬럼명 변경

외래 키와 Map 의 key 가 복합키로 설정되는 것은 의도한대로 잘 생성되었습니다. 하지만 element collection 의 컬럼 명이 제대로 들어가지 않았습니다.

create table select_member (
        poll_item_id bigint not null,
        values varchar(255),
        select_members_key bigint not null,
        primary key (poll_item_id, select_members_key)
    )
Java
복사

컬럼 명을 설정하려면, Column 어노테이션을 사용해야 하고, key 값에 있는 타입을 설정하기 위해서는 @MapKeyColumn 을 활용해야 합니다.

@ElementCollection
@CollectionTable(
        name = "select_member"
)
@MapKeyColumn(name = "member_id")
@Column(name = "description", nullable = false)
private Map<Long, String> values = new HashMap<>();
Java
복사

위와 같이 2개의 어노테이션을 새로 추가한 뒤 다시 실행해 보았습니다.

create table select_member (
        poll_item_id bigint not null,
        description varchar(255) not null,
        member_id bigint not null,
        primary key (poll_item_id, member_id)
    )

alter table select_member 
       add constraint FK1jy0jmpad4ay1rxsw15olkpq7 
       foreign key (poll_item_id) 
       references poll_item
Java
복사

컬럼 명이 잘 생성된 것을 확인할 수 있습니다.

문제 3. embedded 객체 중복 사용

Poll 객체는 도메인 재설계를 하며 기존에 존재하던 Team 객체를 값 객체 Code 타입의 team code 를 가진 간접 참조 형태로 변경하였습니다. 저희는 비즈니스 로직 상, team 에 대한 식별자로 team id 대신 랜덤한 8자리의 unique 제약 조건이 존재하는 team code 를 사용합니다. 그래서 Poll 에서 team 의 식별자로 team id 대신 team code 를 사용하면 효율적일 것이라고 생각하였습니다.

@Entity
public class Poll {

@Embedded
public Code teamCode;

@Embedded
public Code code;

}
Java
복사

여기서 code 는 Poll 에서 식별자로 사용되는 랜덤한 8자리 값입니다. 그래서 team code 와 code(poll cod) 모두 값 객체인 Code 를 활용하였고, 임베드 타입으로 사용하였습니다. 하지만 이로 인해 컬럼 명의 중복이 발생하였습니다. 위의 Poll 객체만 보았을 때는 변수명이 다르기에 아무런 생각없이 문제점을 전혀 파악하지 못했는데, 사실 당연한 문제였습니다. @Embedded 타입은 앞서 언급드렸듯이 @Embedded 타입 내부의 필드를 컬럼명으로 사용하고, 해당 객체의 내부 필드는 code 라는 변수명을 가졌기에, JPA 에서는 Poll 테이블 생성시 컬럼명 중복 예외가 발생하하게 된 것입니다.

@Column 어노테이션 또한 임베드 타입 내부 필드에 적용되기때문에 Poll 객체에서는 해당 필드에서 @Column 으로 구분할 수 없었습니다.

// 불가능!! 같은 예외 발생

@Entity
public class Poll {

@Embedded
@Column(name = "team_code")
public Code teamCode;

@Embedded
@Column(name = "code")
public Code code;

}
Java
복사

‘둘 중 하나만 @Embedded 타입으로 사용하고 다른 하나는 String 을 사용할까,,’ 라는 불손한 생각을 잠깐 하였지만 기술적으로 해결해보고자 하였습니다. 그래서 컬럼에 정보를 줄 수 있는 여러 JPA 의 기능들을 찾아보다가 JPA 의 어노테이션 중 @AttributeOverride 어노테이션을 발견하였습니다. 이 어노테이션은 필드를 오버라이드할 수 있는데, 해당 어노테이션을 활용하면 위의 불가능 예시의 @Column 처럼 Poll 객체에서 사용할 수 있습니다.

@Entity
public class Poll {

@Embedded
@AttributeOverride(name = "code", column = @Column(name = "team_code"))
public Code teamCode;

@Embedded
@AttributeOverride(name = "code", column = @Column(name = "code"))
public Code code;

}
Java
복사

옵션 중 name 은 임베드 타입 내부 변수 중 오버라이드 할 변수명을 지정할 수 있고, column 옵션은 오버라이드하여 사용할 컬럼 명을 지정할 수 있습니다.

재설계 적용 결과

서비스 계층에서 불가피하게 존재했던 비즈니스 로직을 도메인 객체로 옮겨 코드의 응집도를 높이고, 재사용이 가능하게 되었습니다. 덕분에 서비스 계층의 코드의 양도 줄어 핵심 로직 파악에 더욱 유리하여 유지, 보수하기 수월한 코드가 되었습니다. 또한 기존에는 단순히 @Entity, @ManyToOne, Spring Data JPA 메서드를 이용하여 쿼리를 생성하였는데, 설계한 내용을 적용하는 과정에서는 @CollectionTable, @AttributeOverride등의 어노테이션과 더티 체킹을 이용한 쿼리를 사용하여 상대적으로 DB 에 덜 종속적인 객체지향적 구조를 가질수 있었습니다.

하지만 여전히 문제점이 남아있습니다. 이전 게시글에서 쿼리의 성능을 높이기 위해 @Query 어노테이션으로 JPQL 을 생성하여 불필요한 join 쿼리를 없애고, fetch join과 default_batch_fetch_size 옵션 등을 활용하여 N+1 문제를 해결하였습니다. 그러나 현재는 검증 로직과 엔티티 조회를 제외한 모든 쿼리는 JPA 의 더티 체킹에 맡기다보니 또 다시 N+1 문제가 발생하기도 하고, 예상하지 못했던 쿼리가 생성되기도 하였습니다. 이에 따라 쿼리 튜닝을 다시 한번 더 하는 방향으로 잡았습니다. 이에 관한 내용은 다음 포스팅에서 다루도록 하겠습니다.