레거시 코드 리팩터링 미션 초안 정리

blog/2023-4/2023-10-31-레거시 코드 리팩터링 미션 회고.mdx

@@ -0,0 +1,52 @@
+---
+title: 레거시 코드 리팩터링 미션 회고
+slug: refactoring-retrospective
+tags: [Woowahan Techcourse, Retrospective]
+---
+
+:::note PR 링크
+1단계: https://github.com/woowacourse/jwp-refactoring/pull/465  
+2단계: https://github.com/woowacourse/jwp-refactoring/pull/547  
+3단계: https://github.com/woowacourse/jwp-refactoring/pull/610  
+4단계: https://github.com/woowacourse/jwp-refactoring/pull/721  
+:::
+
+### 리팩터링 미션
+
+요구사항 작성 → 테스트를 통한 코드 보호 → 리팩터링 → 의존성 리팩터링 → 멀티모듈 순서로 미션을 진행했다.  
+미션에 온전히 집중하고 싶었지만, 프로젝트와 병행하면서 진행했기에 어느정도 타협보고 진행한 부분이 많아서 아쉬웠다.  
+
+### 1, 2단계
+
+1단계는 요구사항을 작성하고, 테스트 코드를 작성하여 추후에 리팩터링 할 때 안정감 있게 진행할 수 있도록 준비하는 과정이었다. 
+요구사항을 작성할 때 제공된 용어 사전을 최대한 활용하면서 기존의 코드를 보면서 요구사항을 정리했다. 
+테스트는 시간 관계상 API, 서비스 둘 중 하나만 통합 테스트를 진행해야겠다는 생각이 들었다. 
+
+최종적으로 서비스 기준으로 통합 테스트를 작성했는데 약간 후회되는 결정이었던 것 같다.  
+리팩터링 과정에서 API 명세가 바뀌지 않아야 한다는 것을 기준을 잡고 이번 미션을 한다고 가정했을 때 API 기준으로 테스트를 작성하고, 리팩터링을 진행하는 것이 더 안정감 있다고 생각한다.  
+
+2단계는 작성된 테스트 기반으로 리팩터링 하는 미션이었다.  
+서비스에서 도메인을 직접 반환하는 구조였는데, 도메인에 JPA를 적용하면 기존 명세와 달라질 것을 우려해서 DTO로 수정하는 작업을 먼저 진행했다. 
+DTO 이후에 서비스에 있는 로직을 도메인으로 이동시키고, 최종적으로 JPA를 적용하는 순서로 리팩터링을 진행했다. 
+이 과정에서 의존성 방향이 양방향인 부분도 생겨났다.  
+
+### 소프트웨어의 복잡성을 다루는 지혜
+
+소프트웨어의 복잡성을 다루는 지혜는 에릭 에반스의 저서 `도메인 주도 설계`의 부제이다.  
+
+도메인 주도 설계는 유비쿼터스 언어, 전략적 설계, 전술적 설계가 중요하다고 한다.  
+유비쿼터스 언어, 전략적 설계가 전체의 90%에 해당할 정도로 중요하다고 한다. 또한 전술적 설계만 하는 경우를 DDD Lite 라고 한다.  
+간단히 도메인 주도 설계에서 나오는 단어를 정리한다면 다음과 같다.  
+
+| 단어 | 설명 |
+| --- | --- |
+| 도메인 | 소프트웨어로 해결하고자 하는 문제 영역 |
+| 바운디드 컨텍스트 | 해결 영역, 관심사를 분리하고 격리하여 문제 해결에 집중할 범위 |
+| 유비쿼터스 언어 | 프로젝트에 이해관계자들의 공통된 언어로, 서로의 의사소통 비용을 줄이기 위해 사용하는 언어 |
+| 전략적 설계 | 도메인 전문가와 개발자가 함께 유비쿼터스 언어를 이용하여 도메인과 관련된 지식을 이해하고 이를 바탕으로 경계를 나눠 바운디드 컨텍스트를 정의하고, 컨텍스트 맵을 생성하는 것을 포함하는 과정 |
+| 전술적 설계 | 전략적 설계에서 정의한 바운디드 컨텍스트와 도메인을 이용하여 애그리거트, Entity와 VO, Repository 등을 구현하는 과정 |
+
+### 참고 자료
+
+[도메인 원정대](https://www.youtube.com/watch?v=kmUneexSxk0), 우아콘 2021  
+제이슨 강의