개발 디자인 문서

개발을 시작하기 전에, 개발 디자인 문서를 작성하고 팀원들과 공유, 리뷰하는 과정을 거치면 좋은 방향성을 잡을 수 있다. 또한 인수인계 과정에서도 코드와 개발 디자인 문서를 함께 전달하면 비교적 빠른 인수인계가 가능할 것이다.

당장 코드를 먼저 작성하기 보다, 먼저 제약 조건(가용 시간, 인력 등)을 파악한 후, 개발에 대한 고민을 한 후 코딩을 하는 것이 좋다고 생각한다.

문제 정의

  • 배경
    • 현재 어떤 상황이며, 어떻게 해결한 것인가
  • 필수 조건
    • 이 시스템의 성공 조건이 무엇인가
  • 목표
  • 목표가 아닌 것
  • 평가
    • 이 시스템의 성공과 실패를 어떻게 평가할 것인가

해결 방안

  • 설계
    • 다이어그램 필수
  • 구현(Tech stack)
  • 테스트
  • 코드리뷰
  • 모니터링
  • 보안

배포 계획

  • 계획
    • 어떤 유저에게, 어떤 feature 를 … 단계적으로
  • 배포
    • 어떻게 배포할 것인가

타임라인

  • 로드맵(단계별 마일스톤)

고민해야하는 부분

  • 핵심 도메인을 먼저 도출하고 테이블 설계를 진행
    • 테이블은 도메인 객체를 영속화하기 위한 그릇 정도의 역할로 생각
    • 모든 도메인이 꼭 DB 에 저장된다는 보장이 없음 (Ex. VO)
    • 특정 기능을 수행하기 위해 도메인 간에 주고 받아야 하는 메시지를 정의해야 함
  • 변수명, 메서드명에 많은 신경을 써야 함
    • 가독성이 좋아야 함(Clean Code Guide)
    • Ubiquitous Language 개념 처럼 현업에서 사용하는 보편적인 언어를 최대한 반영해야 함
    • 전사 표준 또는 프로젝트 내에서의 네이밍 규칙을 세우고 진행하는 것도 좋음
      • Slack 에서 별도의 채널을 통해 코드 네이밍을 위한 의견을 주고 받는 장치를 마련하는 것도 좋음
  • API 명세에서 요청, 응답의 프로퍼티는 필수 값만 유지되도록 해야 함
    • API 목적에 맞지 않는 응답 값을 내보내는 경우, 추후에 해당 프로퍼티를 제거하기가 어렵게 되어 v2 명세를 새로 만들어서 제공해야하는 경우가 생길 수 있음
    • 요청과 응답 프로퍼티가 너무 많은 경우 해당 메서드나 객체가 처리해야하는 로직이 많다는 의미일 수 있음
  • setter 는 지양 해야 함
    • setter 는 캡슐화된 도메인과 객체를 깨뜨리는 주범이 됨
    • 도메인 객체를 생성할 때에는 생성자를 활용하여 필수값을 객체 생성 시에 받도록 하고, 도메인의 상태를 변경할 때에는 적절한 메서드명을 가지는 상태 변경 로직을 구현해야 함
    • setter 는 어떤 값을 설정한다 의 의미를 담고 있는 메서드이기 때문에, 객체들끼리 메시지(Ex. 결제, 주문 등)를 주고 받을때 setter 를 사용하게 되면 의미 전달이 명확하게 되지 않음
  • transaction 의 사용과 범위 설정은 여러 번 고민 후 결정
    • transaction 은 도메인의 데이터 정합성을 위한 필수 기능
    • 서비스의 성격에 따라 transaction 의 범위를 적절하게 잡는 것이 중요하며, 범위를 작게 잡는 것이 좋음
    • 한 transaction 내에서 외부 3rd party 서비스를 호출하는 로직이 있다면 적절한 타임아웃 설정은 필수이고, 필요에 따라서는 transaction 내에 포함시키지 않는 것도 고려(Ex. 카톡, 문자 발송 등)
  • 꼭 필요한 상태(Status) 만 선언
    • 상태를 너무 세분화하면 도메인을 이해하기 어렵게 만들며, 코드 구현에서도 고려할 것이 많아짐
    • 도메인 객체가 현실에 존재하는 모든 상태를 표현할 필요는 없음. 도메인 객체를 통해 이루고자 하는 기능을 만들어내는데 필요한 상태만 선언해도 괜찮음
  • 핵심 로직의 테스트 코드 작성 필수
    • 변경에 유연한 코드가 되기 위해서는 테스트 코드 작성이 필수임
    • 그렇지 않으면, 특정 기능을 추가하였을 때 사이드이펙트가 많이 발생할 수 있음
  • 리팩토링 필수
    • 테스트 코드를 작성하는 사람이라면 리팩토링은 자연스럽게 할 것이라고 생각 됨
    • 처음에는 동작하는 코드를 우선적으로 작성하고, 기능 구현이 된 이후에 리팩토링을 시도하는 것도 방법

References

  • The Red: 비지니스 성공을 위한 Java/Spring 기반 서비스 개발가 MSA 구축