서비스 분리시 고민할 점 - 이름 정하기

최근의 나의 주요 작업은 하나의 도메인 단위로 서비스를 재구성하는 것이다. 예를 들어, 포인트 관련된 기능이 하나의 DB를 가지고 여러 서버 애플리케이션에서 구현되어 있다면, 포인트 관련된 서비스를 만들고 각 서버 앱들이 포인트 서비스 API를 호출하도록 변경한다. 그리고 포인트 서비스용 DB를 따로 분리한다. 포인트 서비스는 API 수준의 기능을 노출하고 DB는 숨기는 것이다.

작업 방식은 보통 기능을 추출하고 기능단위로 API를 구현하고, 기존 서버 앱들이 해당 API를 호출하도록 작업한다. 굉장히 위험한 작업이기 때문에 기존 서버앱의 수정을 최소화 하고 롤백가능한 구조로 작업을 진행한다.

오늘 적어볼 나의 시행착오는 도메인 모델의 이름에 대한 것이다. 보통 기존 서비스들은 DB의 테이블과 거의 비슷한 명세로 데이터를 주고 받을 가능성이 크다. 그리고 DB의 테이블명과 컬럼명은 약어가 많아 도메인 모델을 표현하는데는 아쉬움이 있다.

그래서 처음 작업할 때에는 테이블과 그에 매핑된 엔티티와 벨류를 아예 다른 이름으로 하는 경우가 많았다. 이렇게 작업 하는 것은 도메인의 표현력을 높이는 장점이 있었다. 

create table pnt_txn
(
    pnt_txn_id bigint auto_increment comment 'PK' primary key,
    mem_id bigint not null comment '멤버 ID',
    pnt int not null comment '포인트',
    -- 생략 ...
)

@Entity
@Table(name = "pnt_txn")
class PointTransaction(
        @Id
        @Column(name = "pnt_txn_id")
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        var id: Long? = null,

        @Column(name = "mem_id")
        val memberId: Long,

        @Column(name = "pnt")
        val point: Int,

        // 생략 ...
)

 

그런데 계속 작업을 하면서 회의감을 느끼기 시작했다. 우선은 결국 해당 API를 사용하는 서버 쪽 코드 수정을 최소화 하기 위해서 이름을 다시 기존 컬럼의 이름으로 어댑팅해야하기 때문에 쓸데없는 일을 너무 많이 하는 느낌이었다. 어댑팅 작업들은 매우 귀찮으며 나의 짜증을 축적시켰다. 그리고 동료들이 이미 예전의 이름에 익숙해져있기 때문에 내가 변경한 이름이 동료들에게는 좀 불편할 수 있다는 생각이 들었다. 기존의 이름들은 파라미터에도 다 녹아있고 여러 맥락에서 공유되고 있는데, 갑자기 내가 이름을 바꿔버리면 또 의사소통 비용이 증가하는 것처럼 느껴졌다.

이런 이유들로 꽤 오랫동안 고민 했다. 고민 끝에 나의 잠정적인 결론은 기존 이름을 유지하는 것이다. 최대한 데이터의 스팩은 그대로 두고 그 외에 기능 수준을 재정의하고 리팩터링 한다. 이렇게 하게 되면서 위의 고민들을 해결할 수 있었다. 실제로 이렇게 결정하고 작업 속도가 증가했다. 어댑팅 코드도 없고, 이름을 바꿀 필요가 없으니 이름을 새로 짓는 고민을 하지 않아도 되기 때문이다.. (고민하면 시간이 정말 많이 든다.) 그리고 그리고 동료들과 그 이름의 맥락을 공유하게 되었다.

이번의 고민은 자연스럽게 도메인에 대한 표현력이라는 것에 대해서 고민하게 했다. 우리는 영어권 국가의 개발자가 아니고, 나도, 나의 동료들도 영어에 익숙하지 않다. 영어 단어를 약어 보단 풀어쓰고 좀 적절한 영어단어를 변수나 메서드명에 사용한다고 해서 동료들이나 내가 코드가 읽기 편해지지 않는다. 뭐가 우리 상황에서 도메인을 최대한 잘 풀어낸 것일까? 특히나 기존 레거시 코드의 표현력을 어떻게 높일 수 있을까?

아직은 잘 모르겠다. 다만 현재는 필연적으로 서비스를 분리해야하고 적당한 시간 내에 이 일을 완수해야한다. 완벽하지 않지만 내가 해결해야할 문제를 해결할 뿐이다. 

 

정리

기존 레거시 서비스에서 특정 컨택스트의 서비스를 추출할 때, 약어들이 가득한 기존 컬럼 명을 기준으로 하는 데이터의 스팩을 읽기 좋은 단어로 변경하려 했으나 코드 수정을 최소화 하며, 이미 동료들에게 편한 용어가 된 기존 데이터 스팩을 변경하지 않기로 결정