[024-help-progress-구조-변경(주요 변경 사항)]

[ScottSung7]

비고: Progress를 강한 참조로 변경하면서 프로젝트의 구조도 같이 변경 하였습니다.

• JPA엔티티는 JPA엔티티끼리, 모델(엔티티)은 모델끼리 있는게 JPA라는 구조에 종속되지 않고 데이터 모델링을 할 수 있다고 생각하여서 JPA엔티티는 인프라 영역에 놓았고 대신에 기존 VO는 도메인에 모델이라는 폴더에 새로 만들었습니다.
• 변경된 파일이 좀 많지만 반복되는 패턴이라 몇가지 커밋만 보시면 될 것 같습니다.
• 첫번째 체크인 변경만 보시면 될것 같습니다. (관련커밋: a0de7b3caa94119c0595c35f6f9f238bb7929619)

주요변경사항

• 구조 추가: 어플리케이션 계층을 만들어 서비스와 도메인을 분리하였습니다.

• 어뎁터 인터페이스로 요청: JPA엔티티와 모델을 서로 인프라와 도메인 영역의 VO로 나누면서 JPA요청은 HelpDBAdapter라는 어댑터를 만들어 어플리케이션 계층에서 인프라에 필요한 정보를 요청합니다. (위치: HelpDBAdapter - 관련 파일링크)

• 리포지토리 통합: 기존에 CheckIn, LineUp, Etc 각자 리포지토리가 있었지만 HelpJPARepository로 통합하였습니다. (위치: HelpJPARepository - 관련 파일링크)

• DTO: 불완전객체 상태를 없애기 위해 중간에 Controller에서 받은 Form을 DTO로 변경해 서비스로 올려보내주고 이후 서비스에서 필요한 정보들을 호출하고 조합하여 모델을 만들었습니다. (서비스) (위치: HelpRegisterDTO - 관련 파일링크)

• 계층구조 1: HelpJPAEntity 와 Help관련 객체들은 상속관계로 이루어지고 HelpJPAEntity와 Help는 추상클래스로서 각각의 최상위 객체입니다. 추상클래스로 이용한것은 Help나 HelpJPAEntity는 실제 구현이 아닌 "틀"로서 이용하기를 원했고 또한, 공유하는 인스턴스 변수가 많아서 상속으로 받는 것이 인터페이스를 통해 implement 하여서 인스턴스 변수를 항상 추가해야 되는 것보다 사용하기 편리하다고 생각했습니다. (위치 1: HelpJPAEntity - 관련 파일링크/ CheckInJPAEntity - 관련 파일링크) (위치 2: Help - 관련 파일링크/ CheckIn - 관련 파일링크)

• 계층구조 2: 그렇다보니 관련 DTO나 Response들도 이런 비슷한 구조로 구현 되었습니다. (위치 1: HelpRegisterForm - 관련 파일링크/ CheckInRegisterForm - 관련 파일링크) (위치 2: HelpSelectResponse - 관련 파일링크/ CheckInSelectResponse - 관련 파일링크)

• 강한참조, 값객체: Progress는 Help와 강한 참조를 가지면서 JPA상에서는 값객체(Embedded, )로 표현되었고 Help의 진행 상태를 나타내는 ProgressVO 인터페이스를 구현하는 객체들로 표현됩니다. 추상클래스가 아닌 인터페이스를 사용한것은 이 인터페이스의 구현체들은 동일한 인스턴스 변수들을 많이 공유하지 않고 상속으로 구현시 오히려 사용이 복잡해질것 같아 중복되는 인스턴스 변수가 있어도 인터페이스로 구현하였습니다. (위치: ProgressValue - 관련 파일링크)

• 모델링에서 값객체: Help에서는 Progress인터페이스로 표현 됩니다. (위치 1: Progress - 관련 파일링크/ Created, Ongoing, Authenticated) (위치 2: ProgressSelectResponse - 관련 파일링크/CreatedSelectResponse,OngoingSelectResponse, AuthenticatedSelectResponse)

• 제네릭: Progress 상태변경시 특정 타입을 강제할 필요가 있을 것같아 제네릭을 추가하였습니다. (위치 : CheckIn - 관련 파일링크)

• 테스트: 테스트는 이 커밋에 넣지 않았지만 Fixture와 Stub을 이용하면서 필요시 모킹을 하는 방법으로 변경하였습니다. 그 이유는 각 테스트 케이스 마다 모킹을 하면 케이스 하나하나마다 스터빙을 해주어야 하는데 이런 조건들이 의도하지 않게 실제 구현과 불일치해서 실제와 다른 테스트를 할 수 있다는 생각이 들었고, 실제 객체를 이용한 테스트가 리팩토링 내성이 높아 더 깨지지 않을것 같기 때문 입니다. (테스트는 다음 PR에 추가하도록 하겠습니다.)

[ScottSung7]

덜어내는 방향으로 더 고민해 보겠습니다.

처음에 Progress를 값객체로 만드면서 Embedded로 Help에 추가하려고 했는데 이게 또 null값인 필드가 생기다 보니 도메인 계층에 두기에 부담이 되어서 JPA객체와 모델 객체를 나누는 작업까지 진행되다 보니까 작업이 한없이 커져 버렸습니다.. 다음에는 좀 더 Divide & Conquer 해서 나누어서 작업하겠습니다!

여기서 JPA 엔티티와 모델엔티티를 나누었던 리팩토링은 과헀던 걸까요..? 아직 아키텍처적으로 어떻게 접근해야 할지 헷갈리는 점이 많은 것 같습니다.

[heeve1]

덜어내는 방향으로 더 고민해 보겠습니다.

처음에 Progress를 값객체로 만드면서 Embedded로 Help에 추가하려고 했는데 이게 또 null값인 필드가 생기다 보니 도메인 계층에 두기에 부담이 되어서 JPA객체와 모델 객체를 나누는 작업까지 진행되다 보니까 작업이 한없이 커져 버렸습니다.. 다음에는 좀 더 Divide & Conquer 해서 나누어서 작업하겠습니다!

여기서 JPA 엔티티와 모델엔티티를 나누었던 리팩토링은 과헀던 걸까요..? 아직 아키텍처적으로 어떻게 접근해야 할지 헷갈리는 점이 많은 것 같습니다.

나누는 것도 충분히 좋은 방향이고 시도해봄직하나 당장엔 현규님 책상에 올라와있는 주제가 너무나도 많은게 문제인 것 같습니다. 당장 작업한게 있긴하니 무조건 뺄필요는 없을 것 같고 빼는게 가능해 보이는(?) 것들부터 조금씩 해보시는건 어떨까 싶네요

[ScottSung7]

이 부분들은 멘토링때 이야기를 많이 나눈것 같습니다. 다만, 상속구조는 조금 더 고민해볼 필요가 있을 것같아 일단 이슈로 빼놓겠습니다. (#91 )