유저 클래스 구조 개선

[jacobhboy]

🔨 Describe
유저 클래스 하나에서 27개의 필드를 가지고 있습니다. 그러나 깃허브에 관련된 정보는 Github, 백준에 관련된 정보는 BaekJoon 이렇게 원시 타입 여러개를 하나로 포장하는 것이 더 좋아보입니다.

장점

1. 유저 클래스의 가독성이 올라간다.
2. 조금 더 객체지향적인 코드를 작성할 수 있다. - Github와 관련된 정보를 User가 처리할 수도 있지만 Github라는 객체에 User가 메세지를 보내는 형식으로 코드를 작성할 수 있습니다.

단점

1. User 객체가 생성될 때 Github와 BaekJoon이라는 객체가 추가로 생긴다.

저는 조금 더 객체지향적인 코드를 사용하는 것이 객체를 추가로 생성하는 것보다 낫다고 생각해서 Github와 BaekJoon으로 값을 포장해야한다고 느꼈습니다.

✅ Tasks

• 1. User 클래스의 Github와 관련된 필드를 모아서 Github라는 임베디드 클래스를 만들고, BaekJoon관련된 필드를 모아서 BaekJoon이라는 임베디드 클래스를 만든다.

🙋🏻 할 말
User 테이블 구조에 대해서 생각을 해보았는데, User테이블이 지금과 같이 많은 속성을 가지고 있는 것은 문제가 되지 않는다고 느껴졌습니다. 오히려 분리하는 것이 데이터의 응집도를 낮춘다고 느껴졌습니다. 이것에 대해서는 어떻게 생각하시나요??

[wonyongChoi05]

문제가 되지 않는 것은 맞지만, 현재 UserTable에 필요 없는 컬럼에 대해서도 너무나 번잡한 싱글테이블로 유지되고 있다는 생각이 듭니다.

위 부분은 제가 만들 때 너무 급하게 만들어서 몰아넣은 느낌이 있는데, 아직 손도 못대고 있구요. 우선 제 입장은 최소한 User와 Github, BaekJoon의 테이블은 나눠야 한다는 의견입니다.

[wonyongChoi05]

저는 3개의 정보가 애초에 다른도메인이라고 생각합니다. User와 Github, BaekJoon이 같은 도메인이라고 생각하시나요??

[jacobhboy]

저는... GIthub와 BaekJoon이 유저의 하위 도메인이라고 생각됩니다. 왜냐하면 독립적으로 존재하기보단 User의 정보로써 존재하기 때문이죠. 다른 도메인이라고 판단한 이유가 무엇인가요??

[wonyongChoi05]

그렇게 따지고 보면 Auth는 왜 Member랑 다른 도메인으로 사용하죠? 위와 같은 논리로 따지면 Member를 위한 정보일 뿐인데요.

[jacobhboy]

그렇지만 Board를 User의 속성으로 볼 순 없죠. Github나 BaekJoon은 User의 속성이 될 수 있다고 생각합니다 !

[wonyongChoi05]

그렇지만 Board를 User의 속성으로 볼 순 없죠. Github나 BaekJoon은 User의 속성이 될 수 있다고 생각합니다 !

예가 잘못되어서 수정했습니다

[jacobhboy]

그렇게 따지고 보면 Auth는 왜 Member랑 다른 도메인으로 사용하죠? 위와 같은 논리로 따지면 Member를 위한 정보일 뿐인데요.

혹시 Auth가 어떤 도메인인지 들어볼 수 있을까요?? 🤔

[wonyongChoi05]

예를 들면 유저를 위해서 RefreshToken을 사용하는데, 이는 Auth 도메인으로 분류해서 사용하는 이유가 있는지 궁금합니다. 따지고 보면 해당도메인의 비즈니스 로직에서는 유저의 정보를 필수적으로 필요로 하는데, 어떻게 생각하세요?

[wonyongChoi05]

위 사진은 부마위키 도메인 구조인데, AuthId도 가지고 있네요? 이것은 유저 정보도 아니고 관련이 있지도 않은 정보인가요? 창보 Lee의 말대로 보면 이 또한 독립적으로 존재하기 보단 User의 정보로써 존재하는거 아닌가요?

그럼 이 부분도 User의 하위 도메인으로 봐야할텐데 도메인을 분리한 이유는 뭐죠?

[jacobhboy]

허걱 부마위키의 코드를 가져오시다니. Auth랑 User는 다른 도메인이라는 것에는 저도 동의 합니다! 왜냐하면 Auth와 User의 생명주기, 즉 생성되는 시간, 사라지는 시간이 완전히 다르기 때문이죠. 하지만 Use와 Github BaekJoon의 생명주는 같습니다 😁. 도메인을 구분하는 관점이 저희가 다른 것 같습니다! 구분하는 기준을 자세히 말해주실 수 있을까요??

[wonyongChoi05]

저는 도메인을 Life Cycle로 분리하지 않습니다. 생명주기라는 것은 애플리케이션을 실행하는 데에 있어서 사용되는 일종의 방식일 뿐이지 도메인을 구분하기 위함이 아니니깐요.

그리고 User와 Github, BaekJoon은 생명주기를 따질 수 있는게 아니라 Stateless한 데이터들입니다. 그럼 데이터베이스 테이블 설계의 관점에서 보는게 더 적합하지 않을까요?

[jacobhboy]

그쵸. 사실 생명주기라는 말이 저도 말하고 이상하다고 느꼈습니다. 그러나 같이 생기고 같이 없어지는 데이터들이기 때문에 같이 존재한다는 것이 불가능한 말 같지는 않아요. 제가 아직 도메인을 잘 구분하지 못하는 것도 있고요.... 원용님의 도메인을 구분하는 기준을 듣고 싶습니다!

[wonyongChoi05]

도메인을 구분하는데에 있어서는 여러가지 요소가 작용할 수 있다고 생각합니다. 저는 웹 개발시 API의 관점에서 보는 경향도 있는 편인데요, 현재 BGIT서비스 특성상 User의 Github정보가 insert되는 타이밍은 깃허브 Oauth 로그인을 할 때고 정보가 수정될 때는 스케쥴러가 동작할때입니다.

하지만 위에서 창보님이 말씀하셨듯이 Auth를 구분한 이유가 있을텐데, 그렇다면 GithubOauth 자체도 다른 도메인의 API로 구분하지 않을까요?

위 기준으로 도메인을 나눈다고 가정할 시 GithubOauth가 UserApiController 내에서 동작해야합니다. 그렇지만, UserApiController가 애플리케이션의 Authenticate까지 책임질 이유가 있을까요?

항상 API를 기준으로 도메인을 분리하는것은 아니지만, 고려하는 순위가 낮지 않은 것은 사실입니다. 이 기준부터 만족이 안되니 다음에 고려해야할 사항으로 넘어갈 수가 없네요.

[wonyongChoi05]

8시에 페어할 시간이어서 조금 서둘러주시면 좋을 것 같아요 ^^

[jacobhboy]

API의 관점에서 본다는 것이 같이 동작되어야한다...랑 같은 말로 생각해도 될까요?

[wonyongChoi05]

무엇이 무엇이랑 같이 동작되어야 한다는 건가요?

[jacobhboy]

도메인을 구분하는데에 있어서는 여러가지 요소가 작용할 수 있다고 생각합니다. 저는 웹 개발시 API의 관점에서 보는 경향도 있는 편인데요, 현재 BGIT서비스 특성상 User의 Github정보가 insert되는 타이밍은 깃허브 Oauth 로그인을 할 때고 정보가 수정될 때는 스케쥴러가 동작할때입니다.

위 기준으로 도메인을 나눈다고 가정할 시 GithubOauth가 UserApiController 내에서 동작해야합니다. 그렇지만, UserApiController가 애플리케이션의 Authenticate까지 책임질 이유가 있을까요?

위의 말이 같이 동작하지 않기 때문에 서로 다른 도메인으로 분리한다...라고 이해가 돼서요! 제대로 이해하고 있는지 궁금합니다

[wonyongChoi05]

맞습니다. 애초에 각각의 ApiController들을 다른 도메인에서 사용할텐데, Auth는 디렉토리는 나눠놓고 User안에서 AuthApiController를 사용하면 그게 일관성 있는 코드일까요?

무조건 정답이라고 보시면 안되고, 이런 기준으로도 분류될 수 있구나. 정도로만 보시면 될 것 같아요

[jacobhboy]

일관성이 없는 코드죠. 도메인을 분리하는 기준에 대한 원용님의 인사이트를 얻은 것 같습니다! 결국은 책임이었네요. 제가 동작으로 객체를 보지않고 속성으로 객체를 봐서 이러한 의견을 가지고 있었던 것 같네요.... ㅠㅠ 객체지향적으로 생각해보면 분리를 하는게 단일 책임을 진다라는 생각이 드네요!

[wonyongChoi05]

창보님 의견으로 코드 반영하셔도 좋습니다. 코드에 정답은 없으니깐요. 그래도 애플리케이션 전체를 먼저 보고 테이블이라던가 객체의 설계를 하면 책임의 분리가 확실해질 때가 많다고 느낍니다.

특히 기능 명세나 요구사항 정의서 같은 부분들을 유심히 보고 정리하면 더 좋구요. 이런 기회를 통해서 인사이트도 얻어가고 개발 실력도 늘어 가는 것 같아 기분이 좋네요^^

앞으로 잘 부탁드립니다.

[jacobhboy]

생각하게 되는 질문들을 계속 받으니 사고를 확장시킬 수 있는 것 같습니다!! 앞으로도 자주 도와주세요🥹 감사합니다 !