본 글에 대해서

회사 수습 기간 중에 한 도메인의 비즈니스 오케스트레이션 서비스를 들여다 볼 기회가 있었다. 해당 오케스트레이션의 취약점을 분석하고 해결 전략을 제시하는 업무를 맡았었다. 그 일을 하면서 본 업무와는 별개로 해당 프로젝트에 대해 코드 레벨 수준의 리팩토링을 제안했었다. 왜냐하면 막상 코드를 읽으니 읽는 것 자체가 너무 어렵고 흐름 파악하는 데 시간이 너무 오래 걸렸기 때문이다. 내 실력이 부족해서 이해 비용이 많이 들었을 수도 있다. 하지만 조금 더 구조화가 잘 되어 있고 코드가 클린했다면 유지보수에 있어서 범용성과 효율성이 많이 높아졌을 것이라 생각했다.

본 글은 그때 리팩토링을 제안하면서 쓴 글을 각색해서 재작성한 글이다. 주요 용어나 실제 코드는 컨셉용으로 대체하였고 민감한 부분은 삭제하였다.

0. 개요

특정 도메인의 오케스트레이션인 sample-processor 서비스의 코드 레벨에서의 현 상황을 진단하고, 개선점에 대해 제안합니다.

1. 배경

관련 이슈에서 발견된 문제점들과 잠재적 문제들을 분석하고 해결책을 찾는 과정 중 sample-processor의 개선이 필요하다고 판단되었습니다.

1. 테스트 코드의 부재→ 작은 수정이 발생하더라도 기존과 동일한 작동을 보장 받을 수 없으므로 수정에 따라 발생하는 리스크가 너무 큽니다.→ 향후 기능 추가 등의 요청이 발생할 때 해당 문제는 더 커질 수 있습니다.
2. 테스트 코드 작성의 어려움→ 현재 작성된 코드에서는 복잡한 코드 구조, 정돈이 필요한 패키지 및 레이어 구조, 많은 중복 코드와 파라미터, 잘 분리되지 않은 책임과 역할 등의 이유로 코드를 읽고 파악하는 데 오랜 시간이 걸리며, 파악을 했다고 하더라도 많은 관련 기능들이 복잡하게 얽혀 있어 단위 테스트 작성이 어렵습니다.
3. 유지보수성과 확장성의 저해→ 이러한 문제는 향후 확장성과 유지보수성을 고려할 때 해결이 필요합니다.

1. 목차

1. 개요
2. 배경
3. 목차
4. AS-IS 및 및 제안
   1. 외부 연결과 내부 비즈니스 로직 처리 패키지를 구분하자
      1. AS-IS 패키지 구조
      2. 문제
      3. 제안
      4. 예시
   2. 비즈니스 도메인에서는 추상화된 행위만 정의하고 세부 로직은 구현 레이어로 밀어넣자
      1. AS-IS 데이터 플로우 및 아키텍처
      2. 문제
      3. 제안
      4. 얻는 것과 잃는 것
   3. 주요 비즈니스 로직과 부가 로직을 분리하자... 최대한 !
      1. AS-IS
      2. 제안
   4. 데이터 전송시 의미 있는 네이밍의 VO를 활용하자
   5. 기타 제안
5. 리팩토링 전략

3. AS-IS 및 제안

1. 외부 연결과 내부 비즈니스 로직 처리 패키지를 구분하자